| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
(cherry picked from commit a6a344d8dfad5f2b8199a0cef6c8f401f5e06db8)
|
|
|
|
| |
(cherry picked from commit b48f9816cd34bfee40825612a33f16215989a937)
|
|
|
|
| |
hostap interfaces. Fixes #6067
|
| |
|
|\ |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Word smithing to remove a bunch of personalization ("You").
|
|/
|
|
| |
More accurate section title.
|
|
|
|
|
|
| |
As per what was done for https://github.com/pfsense/pfsense/pull/2765 -
do it to the rest of them.
Seems to work OK.
|
|\ |
|
| |
| |
| |
| |
| | |
Error: Duplicate ID btnadvppp.
<a class=btn btn-default btn-info href=interfaces_ppps_edit.php id=btnadvppp>
|
|/
|
|
|
| |
This reverts commit a32bed49516f3df3d104a5026a5b2c74451f348f, reversing
changes made to 9ec9978267a5d1985d6da8ba35d52b7174239d2f.
|
|
|
|
|
|
| |
The text of a Form_Button is not translated internally. Some Form_Button
calls already had the button text enclosed in gettext(), this does it
for the remaining ones.
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
At this point $iface is an undefined var. So the last test of this "if" statement is useless.
That code fragment was introduced in commit https://github.com/pfsense/pfsense/commit/e4d40f41aafe00353c0069b457a0b1b0d6c20987
I think that code fragment came from a similar thing that is inside a "foreach $iface" loop in interfaces_pps_edit.php
https://github.com/pfsense/pfsense/blob/master/src/usr/local/www/interfaces_ppps_edit.php#L300
and was pasted into the condition here back in 2011 without being changed.
What I have done to the test here seems what would have been intended. Any better ideas are welcome.
|
|/
|
|
|
|
|
| |
1) The var $iface is not set at lines 2457 or 2464. It is a var that was used higher up local to build_ipv6interface_list() - it is not relevant to the single fields track6-prefix-id--hex and track6-prefix-id-max
2) When the user selects a different track6-interface then trigger update_track6_prefix() which will update the help text track6-prefix-id-range.
Related to forum https://forum.pfsense.org/index.php?topic=107962.msg601309#msg601309
This pull request does not directly address the reported issue of the track6-prefix-id not "taking". It just fixes up some code issues that I noticed.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Correct the Enable Checkbox Var Names
|
|
|
|
|
|
| |
Lease requirements and requests typically contain large lists of options. Set the field width to use the available section space.
Apply a few tweaks for better clarity and consistency between DHCP and DHCPv6.
Include a more information link specific to each advanced panel.
|
| |
|
| |
|
| |
|
|
|
|
| |
interface, we don't want to handle disable separately from everything else, as that discards all the changes other than disabling the interface. Everything else with handling bringing down of interfaces is still handled correctly. semi-related to Ticket #2453
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) Get rid of the stristr() checks to "guess" if an apply button should
be used.
2) Change print_info_box() so it can take a button name of "close"
, "apply" or none to decide which button to show.
3) Delete function print_info_box_np_undo() - nothing calls it.
4) Add new function print_apply_box() to provide an easy wrapper for
print_info_box() with the parameters to be 'warning' level and 'apply'
button.
5) Change print_info_box_np() calls to just print_info_box() or
print_apply_box() as appropriate.
There is 1 direct call to print_info_box_np() from vpn_ipsec_mobile.php
remaining. That tries to make a "create" button. It was not working
before this change. It needs to be sorted out and fixed separately.
After this change there is no dependency on a string containing text
like "apply" to make the apply button appear.
Then we can work on re-engineering the internal code of
print_info_box_np() print_info_box() and print_apply_box() to fit
together however we like. It should be easy to preserving the current
API to print_info_box() and print_apply_box().
|
| |
|
|
|
|
| |
Fixes #5795
|
| |
|
| |
|
|
|
|
| |
If you enter invalid stuff in the interface description - e.g. "123" - and press save, then you get a warning about it, but the breadcrumb changes to "Interfaces: 123" - the wrongly entered description (that was not applied).
If you enter a valid string for 'descr' then by this point $wancfg has the new value anyway and so the breadcrumb will change correctly if you make a valid entry in 'descr' and save.
|
|
|
|
|
|
|
| |
See https://redmine.pfsense.org/issues/5778 for details of how to reproduce the problem.
Note that similar code to make the "Sorry, an alias with the name XXX already exists" message is also at the top of interfaces.inc - it compares the current interface descr from the config with the currently existing alias names. That check would help warn the user if someone managed to add an alias name that matched the interface name. I guess it was there from some time in the past when the alias edit code did not cross-validate the alias name with the interface descriptions. I have left that check there - it does no harm to have it "just in case".
The new code that I added checks the proposed interface description in $_POST against the existing alias names and will give an input_error if there is a match.
|
| |
|
|
|
|
| |
EXCEPT that the link in the help text does not point to the correct place (yet)
|
|
|
|
| |
section
|
| |
|
|
|
| |
https://forum.pfsense.org/index.php?topic=104629.0
|
|
|
|
| |
before updating
|
|
|
|
| |
where required.
|
|
|
|
| |
Remove unused variable $closehead
|
|\ |
|
| |
| |
| |
| | |
Correct section label.
|