luci-base: force menu to regenerate after uci change

[wryun]

Because the menu JSON can have 'depends' in them, uci changes should force the menu to regenerate.

Checklist suggested incrementing PKG_VERSION, but AFAIK for luci this is automatic.

Closes openwrt/luci#6422

• [x] This PR is not from my main or master branch :poop:, but a separate branch :white_check_mark:
• [x] Each commit has a valid :black_nib: Signed-off-by: <[email protected]> row (via git commit --signoff)
• [x] Each commit and PR title has a valid :memo: <package name>: title first line subject for packages
• [ ] Incremented :up: any PKG_VERSION in the Makefile
• [x] Tested on: (arm64, 23.05, Firefox + Chrome) :white_check_mark:
• [ ] ( Preferred ) Mention: @ the original code author for feedback
• [ ] ( Preferred ) Screenshot or mp4 of changes:
• [x] ( Optional ) Closes: e.g. openwrt/luci#issue-number
• [ ] ( Optional ) Depends on: e.g. openwrt/packages#pr-number in sister repo
• [x] Description: (describe the changes proposed in this PR)

[systemcrash]

Sooo, how does this differ from what happened in https://github.com/openwrt/luci/commit/97ebdcbddb9cad76dc551086fcb887e55886a069 ?

[jow-]

This time it tests for a .lua file extension before trying to execute a path as Lua controller. I still don't like this change though, uci depends in menus are meant for feature detection, not for real time display choices. There's other, non-uci depends such as filesystem or acl, those would still show the old caching behavior, leading to inconsistencies.

[systemcrash]

There's other, non-uci depends such as filesystem or acl, those would still show the old caching behavior, leading to inconsistencies.

Could @wryun fix those also in this PR?

[jow-]

It still wouldn't change the fact that the menu would needlessly get regenerated on every single change.

[systemcrash]

It still wouldn't change the fact that the menu would needlessly get regenerated on every single change.

Needless, perhaps. But regeneration still is useful in some cases. Can't we gate those conditions to make triggering it more simple? Evidently there's a need.

[wryun]

From my perspective, I think the current behaviour is confusing, and realistically the cost of regenerating the menu vs the speed of applying changes in luci is low (any change automatically has a 4 sec hold-off, so what this adds is tiny by comparison).

Even without fixing the filesystem/acl stuff - which aren't currently causing user-facing issues, AFAIK - I think this is a useful improvement.

Note that even with the current base OpenWrt it can cause issues if people load the interface before the startup/hotplug stuff has finished: https://github.com/openwrt/luci/issues/6422#issuecomment-1685595413

[systemcrash]

Closing this in favour of #7725