back to phpList.org

Can't seem to change the 'transactional settings'


#1

Under Config / Settings ( /?page=configure )

I changed the wording of a few messages, but when I test it, the old messages are still used ?
I hit the ‘save’ button on all individual message changes. I even logged out and back on, to see if they were truly saved (they are).

The top of the page seems to suggest there is another (?) save button ?
"You can edit all of the values in this page, and click the “save changes” button once to save all the changes you made."
But I don’t have that button ? Only a ‘Reset to default’ button.

Am I missing something ?


#2

All that means is that you can change multiple values, then click one of the Save buttons to save all your changes. IE: you don’t have to click save each time to change a value when you are making several changes.


#3

I found the texts that are being used under Config / Subscribe pages

It’s confusing. I assume / Settings is used as default for a new subscribe page ?


#4

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. :confused:


#5

I think the following test scenario amply demonstrates why the current structure is wrong.

The gist of it is that a (test) subscriber received the unsubscribe transaction message defined in a subscribe page that the subscriber never used.

It could make sense to use a phpList default or the Settings default for such a subscriber, but it does not make sense to pull that transactional message from a subscribe page that the subscriber never saw or used.

My test was as follows:

  1. Create a CSV with a test subscriber
  2. Import the CSV and select a test list that is not shown on any subscribe page
  3. Send a campaign to the test list
  4. Use the unsubscribe link in the email received by the test subscriber
  5. Compare the content of the unsubscription transaction message received by the test subscriber against the “default” message defined in Settings and the message defined in an actual subscribe page.

What I should have seen: A message other than the one defined with the subscribe page (because that subscribe page was not used)

What I saw: The message defined with the subscribe page.


#6

@Crenel84 Thanks for the clear illustration of the problem. Would you be able to turn that into a mantis feature request in order to outline a solution that can then enter the release roadmap? FYI @Suela


#7

I will give it a try this weekend. I’m pretty unfamiliar with Mantis but should be able to figure it out eventually!


#8

@Crenel84 Just make sure you have the right project selected top right when you report the issue, and leave all fields that you’re unsure about blank in the reporting form (you should only really need the title and description). Good luck!