a) When we are doing combined fields and usecolspan2 is in effect, then usecolspan2 is also a signal that we want to spread the combined fields horizontally in a single row. In that case we want the combined fields to all be in a single "tr" tag enclosing them all. That was already working in that way.
b) But if usecolspan2 is NOT in effect, then we want the combined fields to still run "together" but vertically under each other. In this case we want each field to be in its own "tr" tag.
This change makes (b) happen.
If combinedfields is not set, then each of the "if" tests here still follows the same path it did previously, so there should be no effect on the HTML output for any ordinary package fields.
Actually the "tr" tag needs to be a single tag-pair that encloses all of the set of fields with combinedfields specified - combinedfields=begin is where the "tr" tag starts and combinedfields=end is where the "tr" tag ends, enclosing a whole set of combined fields.
That allows usecolspan2 to work.
In the previous change I had made it enclose every field in its own "tr" tag-pair That caused usecolspan2 to be ineffective at spreading the combined fields across the display.
Also colspan needs to be initialised each time around the loop - it was getting applied to all fields further down the page after the first one it was used in.
This is the version for 2.2.*
Even with this fix, the code does not make sense. The first test is:
if ($startingat > -1)
if it gets into the else, then $startingat must be negative. But the test in the "else" tests for >1 ???
Someone who knows what it really is supposed to do could fix it!
These "if data" tests look like they should apply to all 4 lines below them.
After sorting out this real-looking issue, I can mess with the rest of the formatting...
1) Variable $i is was set, incremented and not used.
2) "if preg_match" at line 94 had no curlies after it, so it was only applying to the first line after it ($rdr_proto = ...) It really looks like "if preg_match"should apply to the whole code chunk - settings the various "rdr*" vars and then spitting out the "tr" with the various matches values in the row.
Somebody with some various UPnP enabled and running should test this to see if the status page still works with this change.
I think it only makes a difference if $rdr_entries has some lines in it that do not match the regex - in that case the old code might have displayed some rubbish or (almost?) duplicated rows.
This change makes it possible to have host with identical hostnames in different (sub)domains. For example myhost.sales.acme.com and myhost.support.acme.com will now be possible.
This should be the end of a "tr" here.
Browsers seem to be forgiving of this stuff - I don't see any difference in rendering in Firefox before or after this change.
This file seems to have an unmatched "td" ending. Adding the line here matches the "td" at line 320 and this embraces the little table that has the 4 icons in it in a square that comes at the right hand end of each port-forward entry in the main table.
I can't see any difference in the rendering of the page, at least on Firefox, with and without this fix.
The tabbing of this file is woeful. I am fixing that up with a code-style review. But thought I should do a separate pull request for this kind-of-functional fix.
If the DHCP IP address is in a pool (not in the main DHCP range for the interface) then the interface that corresponds to the IP address is not found. This results in the link to "add static mapping for this MAC address" not having any value for "if=" and thus clicking on the "+" button does not work.
Reported in bug 4649
Process any pools when checking for which interface contains the IP address.
If I go to Service->DHCP Server, make some edits that are invalid (e.g. change range start or end to some invalid string) and press Save then the page comes back displaying the input error(s). But it also says:
"The changes have been applied successfully."
Actually, the changes (which were invalid) have not been applied to the config - all is well there - but dhcpd has been stopped and started and dnsmasq or unbound has been kicked... which is all unnecessary processing since the user has not yet provided valid values to save.
Actually the GUI is displaying the opposite setting to what is in the config. When the user pressed save that opposite setting was saved, but then again it displays the opposite of the opposite...
I noticed this when cleaning up VIPs and OpenVPN server when testing for this forum post https://forum.pfsense.org/index.php?topic=92174.0
The system let me delete my test VIP before I deleted the OpenVPN server using, probably not a good thing.
This is a better version of #1604 - the similar loops for server and client are combined, and the error message shows the description (or IP address:port) of the offending OpenVPN instance so the user has a clue about which OpenVPN instance uses the VIP.
Tell users that this is possible in DNS Resolver and how to achieve it. The code in unbound.inc already supports it and works.
I had asked for this in Redmine feature request #4350 and when I went to look at coding to implement it I found code that already did it.
So IMHO it is worth telling users.
Note that advertise is spelt with an "s" in other places in the GUI, so
making it consistent in services_ntpd - but maybe Americans do spell it
"advertize" these days?
this helps pick a free port for services using sockets bound to localhost, and helps determine if the service has at least started and bound the port without needing to go through all 'connected' sockets as well
