Feature #6753

Interfaces list order not consistent

Added by robi robi 6 months ago. Updated 10 days ago.

Web Interface
Target version:
Start date:
Due date:
% Done:



The order the interfaces are listed in several places:
- Status > Interfaces
- Dashboard Interfaces widget
- Interfaces menu

The interfaces menu populates the list alphabetically, while all the other places where multiple interfaces are shown, are populated in the order they appear in config.xml. The order should be consistent. I vote for sorting alphabetically everywhere. Or, if possible, create a GUI page where their order in config.xml could be customized :-)

Associated revisions

Revision e5d33973
Added by Steve Beaver 4 months ago

Fixed #6753
Interface menu entries no longer sorted for consistency with other GUI instances

Revision 96ff627f
Added by Steve Beaver 4 months ago

Fixed #6753
Interface menu entries no longer sorted for consistency with other GUI instances

(cherry picked from commit e5d339735836fd55b0fa944d5d7e472793785e30)


#1 Updated by Jim Thompson 4 months ago

  • Tracker changed from Bug to Feature
  • Category set to Interfaces
  • Assignee set to Steve Beaver

#2 Updated by Steve Beaver 4 months ago

  • Category changed from Interfaces to Web Interface
  • Status changed from New to Feedback
  • Assignee changed from Steve Beaver to robi robi

Sorting has been removed from the Interface menu.

Adding msort to all other occurrences would obviously involve more work/risk, and there is some merit to leaving the list unsorted/defined by the hardware.

#3 Updated by Steve Beaver 4 months ago

  • % Done changed from 0 to 100

#4 Updated by Luke Hamburg 17 days ago

Can I protest against this change? I upgraded to 2.4 and so far this is the only change that is really causing me a lot of grief. On systems with many interfaces/VLANs this should count as a regression, it makes it quite a lot harder to spot the interface you are looking for.

Instead of removing the perfectly-working sort on the interfaces menu, why can't we move in the other direction as Robi suggests and make the rest of the menus adopt the same sort order. I disagree with Steve's comment that leaving the list unsorted has any merit.

#5 Updated by Jim Pingle 17 days ago

  • Target version set to 2.4.0

The interface order on Interfaces > Assignments is significant for HA purposes but otherwise alphabetical tends to be easier to deal with for users with a large number of interfaces. I could see significant portions of people wanting this to work both ways, maybe we need to make it an optional behavior instead of forcing it.

#6 Updated by robi robi 17 days ago

+1 for making the interfaces list sorted alphabetically by their DESCRIPTION (NAME) defined in /interfaces.php.

This is not just about aesthetics. There are many situations where interfaces with similar purposes are added at different times, this causes a mess. For example you have a WAN from the beginning, that's somewhere at the beginning of thelist, but after some time you get multiple wans, you add a new interface, that will be at the end of the list. When you have 20 or more interfaces, it drives you nuts to find the various WANs mixed between so many LANs. There are events when new temporary interfaces are needed, and I name them like GUEST_1, GUEST_2 and so on, WORK_1, WORK_2 etc. and unless these interfaces are created immediately one after the other aplhabetically, they will be all mangled in a big mess. (for example if I create GUEST_1, WORK_1, WAN2, WORK_2, GUEST_2 in this order, they will not be alphabetical anymore). Moreover, if I reuse some older OPT interface instead of creating a new one, that will stick somewhere in the middle.

Even worse, if I create VPNs and assign interfaces to each leg, mess will become even bigger. It would be logical if I could simply call them VPN_SITE1, VPN_SITE2, VPN_SITE3 etc they would at least grouped next to each other. WAN1 and WAN2 the same, LAN_1, LAN_2 etc the same.

This order needs to be kept everywhere where interfaces are listed by their description.

#7 Updated by Jim Pingle 10 days ago

  • Status changed from Feedback to Assigned
  • Assignee changed from robi robi to Steve Beaver
  • Target version changed from 2.4.0 to 2.3.3

#8 Updated by Jim Pingle 10 days ago

  • Assignee changed from Steve Beaver to Jim Pingle

I'll take this, looks like maybe the consistency doesn't weigh up against the inconvenience of the menu being unsorted so I'll revert it.

#9 Updated by Jim Pingle 10 days ago

  • Status changed from Assigned to Resolved

Commit reverted.

Also available in: Atom PDF