View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0019661||phpList 3 application||Configuration||public||02-01-19 10:37||11-01-19 23:04|
|Platform||linux||OS||?||OS Version||php 7.2|
|Summary||0019661: website config settings not being used in phpList|
|Description||Admin changes config/settings on web interface for subscribe message and confirmation message.|
Web interface shows updated wording for messages.
when subscribe and confirmation messages are sent, the system uses old version of text.
|Steps To Reproduce||see description|
|Additional Information||phplist_config file has multiple entries... confirmation message, confirmation message.1, confirmation message.2, confirmation message.3, ... confirmation message.n|
the 'correct' text to use is in confirmation message. the system seems to be using confirmation message.7 when sending.
|Tags||No tags attached.|
This sounds like the confusion of "central config" vs "subscribe page" config to me.
Isn't there a new button for that now?
||@michiel the new button allows admins to easily 'Reset to default' a custom subscribe page. The default is whatever is centrally configured on the settings page.|
||@samtuke, I presume your last comment was for @danwaterloo instead of me.|
||Not sure if I am understanding this right but editing those texts on the "Settings" page will make every subscribe page created after then get the changes by default. Any other existing subscribe page will have the old version of the text and you will need to make any changes directly on the "Transaction Messages" section of each subscribe page.|
||The reset button is only for the style, not for transaction messages.|
danwaterloo was working on my site when the bug turned up. It's over my head but I can add the issue is not confined to the subscribe page and transaction messages. Dan added adefine(‘SEND_QUEUE_PROCESSING_REPORT’,false); to config.php. It didn't stop phplist from generating processing reports. Dan had to go directly into the database to manually include the line to make it effective, just as he had to manually add updated text for the transaction messages. So there's a larger disconnect between the web/interface and the database.
Other functions - working with lists, subscribers, setting up posts and sending to a list - work fine from the web interface. The issue may be confined to particular areas of the settings: config.php and config/settings, particularly the transaction messages, as I'm sure they have the problem. But there may be other areas suffering from the same.