At the moment the user can answer "yes" to most of the questions, but then later code only checks if the answer is "y". Thus you can type in "yes" in some places, have it accepted, but actually the negative action is taken. That is weird and will mess up people who try typing a whole string starting with "y".
With this change it makes the user type one of "y", "yes", "n", "no". When they type 1 of those, it is turned into either "y" or "n". Then the existing implementation logic all works as expected.
Hopefully this is the "final" version that fixes the behavior of the (y/n) questions.
I also included the bit at 296-297 which adds the CIDR bit-count range to the prompt, so the user can see exactly what input is valid/expected there.
Redmine issue #4100
Currently this allows the user to input any number for the CIDR. I happened to try 44 for an IPv4 CIDR when playing.
This fixes that little bug - I think it is good to commit that first/separately so it can be identified apart from the other (y/n) checking/handling I am working on. Better to have separate commits for distinct bugs.
I had a 2.1.5 system that I was wondering why the dashboard always said it could not check for updates. I discovered it had "Use an unofficial server for firmware upgrades" checked, but the "Base URL" field was empty.
That can easily be checked with input validation - might as well catch dumb things like that.
I thought about making it parse the string to see if it seemed like a "valid" URL. But so many strings seem like valid URLs:
var_dump(parse_url("abc"));
array(1) {
["path"]=>
string(3) "abc"
}
It seemed a bit pointless to bother - if the user puts something in then hope that it might point to something some day.
- Remove redundant declaration of $icmptypes and move it to a common
place (filter.inc)
- Add missing ICMP types for v4
- Add ICMPv6 types
- Adjust javascripts to show correct options depending of IP Protocol
- Hide ICMP type selection when protocol is IPv4+v6
It fixes#3389
- When interface is 'lo0', strpos returns 0, that is erroneously
considered false (boolean) on the test. Be more strict on strpos return
to avoid skiping lo0 ip aliases during sync.
Alternate version of https://github.com/pfsense/pfsense/pull/1376
This version retains the is_array() checks and then only does the count() if the is_array() is true.
Take whichever version you like.
Forum: https://forum.pfsense.org/index.php?topic=85187.msg467438#msg467438
The bold is specified literally in gateways.widget.php for the gateway IP box, so we need to send it bold from here also when providing an update.
Because this now uses a "/" in the string (to terminate the bold) have to choose another delimiter between the status text and status color - picked "^" because I can't think where it will appear elsewhere in the real data.
This whole string of stuff that is returned by getstats.php back to the browser is a long string with a bunch of delimiters inside delimiters already (vertical bar separated fields, inside that comma-separated fields...) and is already subject to stuff going wrong if any of the real text in the fields contains a vertical bar or comma or... Not about to try to re-engineer all that right now!
Recent commit 9ea554ee5c added testing of the return status of console_configure_dhcpd() - this let a user effectively abort from doing anything if they have answered "y" to prompt_for_enable_dhcp_server() and are being asked for the start and end of the range, and then decide they do not want to proceed.
However, even when they gave good answers, status 0 was being returned. This prevented changes ever being implemented.
Redmine: https://redmine.pfsense.org/issues/4080
The fix is to return 1 at the routine end, when all is good and the code should proceed.
On Status->Services, the Services Status widget when a service status is down, the red "x" button does not line up with the green "running" button in the column.
This is because listbg has:
padding-right: 16px;
But the normal listr has:
padding-right: 6px;
It seems really odd that listbg as 16 pixels right padding. I expected it to have all the same padding as listr, just with a different color.
listn and listbggrey have the same "feature" of extra padding-right.
listn does not seem to be used anywhere anyway - might as well "fix" it in case something uses it some time.
listbggrey seems to only be used by pkg_mgr_installed.php in the case when an installed package version is in advance of the online version - quite an unusual thing! Changing padding-right from 16px back to 6px is fine for that.
Then the "feature" is lso in listhdr and listhdrr - lots of examples like firewall_aliases.php have the column headings as listhdr or listhdrr, so in theory if the column is not so wide already, it will put 16px on the right after the column heading text. But the actual rows of data underneath use listr and listbg, which only specify 6px right padding. In the end it usually does not make any difference - there is space already and the browser lines it all up anyway. But it seems to me an odd difference in the css.
listtopic also has this 16px right padding thing - but it seems to be used just for text display that is not in columns, so I did not mess with that.
Changing this css fixes the lineup of the red "x" in the services status column and does not seem to break anything else. In theory it could make other things better also.
Someone who knows how the css was intended to be used could comment on this! If I have got the right idea, and these "16px" things were just a mistake from the past, then it should be checked in the css for all themes and corrected appropriately...
I am happy to do that, once someone confirms it is the thing to do.
Make sure pf is configured before other services are restarted when WAN
IP changes. The way it was before, 'pass out' rules with route-to still
have old IP set as 'from' and some Dynamic DNS ended up not being
updated.
getstats.php calls functions.inc.php get_stats(), which calls get_gatewaystats().
get_gatewaystats() now returns the text for each field and an optional color separated by "/" - "text/color" e.g. "Online/#90EE90"
Parse the the new format, separating out text and color.
If color is specified, then also set it with jQuery to css.
This code was passing a whole load of html to attempt to set various properties of the Gateways Widget Status column so that it would display the new status (Online, Offline...) and in the appropriate color.
Now that I am using class=listr, the css fro listr already specifies white. Setting bgcolor in HTML does not override that.
Pass both the status text and color as ordinary text, separated by "/". The consumer of this output can do their thing with jQuery to set the color as well as text of the element.
The Gateways Widget Status was not using the listr class, and so it was missing the borders for the right and bottom of its box.
Use the listr class.
Then use javascript to explicitly set the background-color to match the status, overriding the white that is specified in listr.
