Currently if the user is clicking around while they are setting up an OpenVPN server, they can do stuff like this:
a) Select Server Mode - Remote Access (SSL/TLS + User Auth)
b) Select something in Backend for authentication
c) Change their mind and select Server Mode - Peer to Peer (SSL/TLS)
d) Enter the other settings and Save
Now the OpenVPN server config has an 'authmode' key in it.
Probably does no harm, I suspect it will simply not be used when building the server.conf for Peer to Peer, but it looks a bit odd when analysing/diagnosing a config for problems.
Other fields that are mode-specific have tests to only save the values at the end if the appropriate mode is the one finally selected.
While I am here, I also constantly forget to click on "Local Database" authmode when setting up a new server. It gives the validation error message, then I click on "Local Database" again and save. Seems unnecessary - when defining a new OpenVPN server why not default this to have the first entry in the list be the one selected? So I did that. What do you think? 1 place less for many users to need to click.
IMHO it can be confusing on the DHCP edit page for static mapped entries to know which interface the entry is being edited/added for. Specially if the user comes from the Status DHCP Leases page, the lease they are editing/adding could be for 1 of many LAN-style interfaces.
This also made it easier for me to see which interface entry I was editing when I was testing https://github.com/pfsense/pfsense/pull/1504
The edit button for static entries always has an index id=0 and thus pressing the edit button goes to (mostly) edit the wrong entry.
It was easier and made the code cleaner to get rid of the looping through the staticmap array every time trying to matach IP, MAC address... That data ('if' and 'staticmap_array_index') is easily gathered further up, the first time the staticmap array for each DHCP interface is traversed. I think this should also be more efficient when there are many static mapping entries.
Forum: https://forum.pfsense.org/index.php?topic=89072.msg493241#msg493241
The domain override is IP:port is invalid if either the IP address OR port is invalid.
Previously you could put an invalid IP with valid port, or valid IP with invalid port.
Many thanks to Gertjan in forum https://forum.pfsense.org/index.php?topic=87504.msg484017#msg484017
Specifically setting the output encoding to latin-1 was causing the "black diamonds" for special characters in the http://blog.pfsense.org RSS feed (e.g. the registered trademark sign after pfSense did not come out).
It should all work by letting simplepie do its default stuff with the RSS feed.
https://redmine.pfsense.org/issues/4176
Allow the user to choose SMTP authentication mechanism PLAIN or LOGIN.
For existing configs with this option not set, PLAIN is the default, and will appear first in the dropdown box, so next time the user saves the SMTP Notification settings, PLAIN will be the value selected and saved.
Forum: https://forum.pfsense.org/index.php?topic=86808.0
Redmine: https://redmine.pfsense.org/issues/3886
print_info_box_np() when called with just the first $msg parameter has some rough tests to decide if the "Apply" button should be displayed. It checks if the translation of "apply", "save" or "create" appears in the $msg string (which is a translated string itself). If the $msg string did not translate, and thus remains in English, but gettext("apply") does translate then the e.g. Turkish word for "apply" is not going to appear in the English $msg string. So things go wrong.
print_info_box_np already has extra parameters to tell it explicitly $showapply - and for this stuff we know we want the apply button, regardless of how the various text string translations work out. Thus I have provided those parameters here.
I also changed the construction of the text to pass as $msg, breaking it up like in firewall_aliases.php - this means that the string "You must apply the changes in order for them to take effect." translates and you get at least that Turkish displayed.
IMHO it would be beneficial to change lots of these print_info_box_np calls to explicitly set $showapply=true - that will ensure that the apply button shows (and thus the user can perform the needed actions) regardless of how well/not well the translation of the text turns out.
