Fixes, Changes & Improvements After Review

[Martinski4GitHub]

Lots of changes have been made so that future reviews are much easier. The Linter tool reported over 850 warnings combined (both shell & ASP files) so the really significant warnings were buried with all the rest. To remedy this, lots of changes were made simply to comply with our coding style & standards and remove over 700 warnings.

But also, some fixes and improvements were made to both the shell script and the HTML/JavaScript code (too numerous to list them all).

Heere are significant changes to the way we used to do some things:

1. The "Lock" file now has a "type" parameter so that we can differentiate between "CLI Menu calls" vs "CLI option" calls.

2. There are 2 new CLI parameters:

   • Parameter install to run the installation routine which downloads, install & set up the files, including the webGUI page.
     /jffs/scripts/MerlinAU.sh install

   • Parameter startup to run initialization routines following a router reboot, including setting up the webGUI page.
     /jffs/scripts/MerlinAU.sh startup

3. One additional entry is added to the "services-start" hook script to automatically run the "startup" call.

4. The WebGUI page was modified to show different statuses with different colors to readily see what's enabled, disabled, or TBD.

5. Added "check and validation" routines for the option to set the number of postponement days to make sure only valid values are allowed and eventually written to the config file.

[Martinski4GitHub]

@ExtremeFiretop,

Due to all the significant changes made to the way some things were done before, I would strongly recommend removing all traces of the previous "installation" of the WebGUI page (entries in the "/jffs/addons/custom_settings.txt", "/tmp/menuTree.js", "service-event", "services-start" files) so that you start with a "fresh & clean" installation.

Here are some screenshots:

[ExtremeFiretop]

Heere are significant changes to the way we used to do some things:

1. The "Lock" file now has a "type" parameter so that we can differentiate between "CLI Menu calls" vs "CLI option" calls.
2. There are 2 new CLI parameters:

Does this address the situation when someone has the shell script loaded and is playing with settings in the WebUI at the same time? That was the last issue I still had to address that was on my to-do list hahaha

[ExtremeFiretop]

@ExtremeFiretop,

Due to all the significant changes made to the way some things were done before, I would strongly recommend removing all traces of the previous "installation" of the WebGUI page (entries in the "/jffs/addons/custom_settings.txt", "/tmp/menuTree.js", "service-event", "services-start" files) so that you start with a "fresh & clean" installation.

Here are some screenshots:

Will do!

I can uninstall the old version and then test with a clean install ;)

[Martinski4GitHub]

Heere are significant changes to the way we used to do some things:

1. The "Lock" file now has a "type" parameter so that we can differentiate between "CLI Menu calls" vs "CLI option" calls.
2. There are 2 new CLI parameters:

Does this address the situation when someone has the shell script loaded and is playing with settings in the WebUI at the same time? That was the last issue I still had to address that was on my to-do list hahaha

Yes, that was the intended goal. One can have the SSH CLI menu open, while the WebGUI page is also running, and then select actions to perform. But, of course, they do not actively keep polling the configuration file so any changes made from one UI will not be reflected on the other immediately; you'll have to "refresh" the UI in order to re-read the modified configuration file. But this is the case for every add-on that is available out there; it would not be a unique limitation.

[Martinski4GitHub]

@ExtremeFiretop,

I just submitted some simple changes to adjust the width to account for the possible long string of "ProductID / ModelID" in the rare cases where they happen to be different.

Here is a "fake example" just to illustrate the case.

[ExtremeFiretop]

@ExtremeFiretop,
Due to all the significant changes made to the way some things were done before, I would strongly recommend removing all traces of the previous "installation" of the WebGUI page (entries in the "/jffs/addons/custom_settings.txt", "/tmp/menuTree.js", "service-event", "services-start" files) so that you start with a "fresh & clean" installation.
Here are some screenshots:

Will do!

I can uninstall the old version and then test with a clean install ;)

For fun, I just tried to replace the .asp file and
Sh file without a fresh install, and oh boy! Don't do dat.

Fresh install is a STRONG recommended coming from my previous 1.4.0

After clearing everything from the old 1.4.0 and reinstalling the production 1.3.9 and upgrading to this gave me the expected result.

Will start testing this evening!

[TheS1R]

Heere are significant changes to the way we used to do some things:

1. The "Lock" file now has a "type" parameter so that we can differentiate between "CLI Menu calls" vs "CLI option" calls.
2. There are 2 new CLI parameters:

Does this address the situation when someone has the shell script loaded and is playing with settings in the WebUI at the same time? That was the last issue I still had to address that was on my to-do list hahaha

Yes, that was the intended goal. One can have the SSH CLI menu open, while the WebGUI page is also running, and then select actions to perform. But, of course, they do not actively keep polling the configuration file so any changes made from one UI will not be reflected on the other immediately; you'll have to "refresh" the UI in order to re-read the modified configuration file. But this is the case for every add-on that is available out there; it would not be a unique limitation.

Might you consider adding additional menu options in shell script for both the main menu and the Advanced Options Menu to perform a user initiated menu refresh (i.e., reload configuration file on demand)? Skynet currently does this as "[r] --> Reload Menu".

[Martinski4GitHub]

Heere are significant changes to the way we used to do some things:

1. The "Lock" file now has a "type" parameter so that we can differentiate between "CLI Menu calls" vs "CLI option" calls.
2. There are 2 new CLI parameters:

Does this address the situation when someone has the shell script loaded and is playing with settings in the WebUI at the same time? That was the last issue I still had to address that was on my to-do list hahaha

Yes, that was the intended goal. One can have the SSH CLI menu open, while the WebGUI page is also running, and then select actions to perform. But, of course, they do not actively keep polling the configuration file so any changes made from one UI will not be reflected on the other immediately; you'll have to "refresh" the UI in order to re-read the modified configuration file. But this is the case for every add-on that is available out there; it would not be a unique limitation.

Might you consider adding additional menu options in shell script for both the main menu and the Advanced Options Menu to perform a user initiated menu refresh (i.e., reload configuration file on demand)? Skynet currently does this as "[r] --> Reload Menu".

I like the general idea but not as an explicit menu option duplicated in multiple places.
What about some key combination that would trigger the "user-initiated reload of the configuration file" whether from the Main Menu or the Advanced Options menu? This way there are no duplicate options in different menus.

[Martinski4GitHub]

@ExtremeFiretop,

I just submitted a new commit with improvements to the script-locking mechanism. Please use this latest code for testing & validation.

[TheS1R]

Heere are significant changes to the way we used to do some things:

1. The "Lock" file now has a "type" parameter so that we can differentiate between "CLI Menu calls" vs "CLI option" calls.
2. There are 2 new CLI parameters:

Does this address the situation when someone has the shell script loaded and is playing with settings in the WebUI at the same time? That was the last issue I still had to address that was on my to-do list hahaha

Yes, that was the intended goal. One can have the SSH CLI menu open, while the WebGUI page is also running, and then select actions to perform. But, of course, they do not actively keep polling the configuration file so any changes made from one UI will not be reflected on the other immediately; you'll have to "refresh" the UI in order to re-read the modified configuration file. But this is the case for every add-on that is available out there; it would not be a unique limitation.

Might you consider adding additional menu options in shell script for both the main menu and the Advanced Options Menu to perform a user initiated menu refresh (i.e., reload configuration file on demand)? Skynet currently does this as "[r] --> Reload Menu".

I like the general idea but not as an explicit menu option duplicated in multiple places. What about some key combination that would trigger the "user-initiated reload of the configuration file" whether from the Main Menu or the Advanced Options menu? This way there are no duplicate options in different menus.

Yes, that would be a great way to implement it! I didn't like the duplicated menu options either, but without a way to initiate a reload from either menu, one would need to exit completely out of the script — your solution avoids that.

[Martinski4GitHub]

Heere are significant changes to the way we used to do some things:

1. The "Lock" file now has a "type" parameter so that we can differentiate between "CLI Menu calls" vs "CLI option" calls.
2. There are 2 new CLI parameters:

Does this address the situation when someone has the shell script loaded and is playing with settings in the WebUI at the same time? That was the last issue I still had to address that was on my to-do list hahaha

Yes, that was the intended goal. One can have the SSH CLI menu open, while the WebGUI page is also running, and then select actions to perform. But, of course, they do not actively keep polling the configuration file so any changes made from one UI will not be reflected on the other immediately; you'll have to "refresh" the UI in order to re-read the modified configuration file. But this is the case for every add-on that is available out there; it would not be a unique limitation.

Might you consider adding additional menu options in shell script for both the main menu and the Advanced Options Menu to perform a user initiated menu refresh (i.e., reload configuration file on demand)? Skynet currently does this as "[r] --> Reload Menu".

I like the general idea but not as an explicit menu option duplicated in multiple places. What about some key combination that would trigger the "user-initiated reload of the configuration file" whether from the Main Menu or the Advanced Options menu? This way there are no duplicate options in different menus.

Yes, that would be a great way to implement it! I didn't like the duplicated menu options either, but without a way to initiate a reload from either menu, one would need to exit completely out of the script — your solution avoids that.

OK, it's on my to-do list :>).

[TheS1R]

@ExtremeFiretop,

I just submitted a new commit with improvements to the script-locking mechanism. Please use this latest code for testing & validation.

Testing with this latest commit (most likely not caused by commit), I discovered an inconsistency between how reloading settings do or do not happen when switching between main menu and Advanced Options Menu (or reverse) in shell script — toggling a checkbox is handled differently than chnaging value in text box.

Scenario:

1. Launch shell script. Note state of menu item 3 (F/W Update Check) and value of menu item 4 (F/W Update Postponement Days).
2. Launch web UI.
3. Toggle Enable F/W Check in web UI.
4. Change value of F/W Update Postponement in web UI.
5. In shell script (still on main menu page), enter "ad" to go to Advanced Options Menu, followed by "e" to return to main menu — menu item 3 toggled, but value of 4 remains unchanged.
6. Enter "e" to exit script.
7. Relaunch script. Both menu options now match web UI changes.

This scenario appears to be consistent when toggling checkboxes or changing values on both menus.

Suggested Solution: Force a reload of configuration file whenever switching from main menu to Advanced Options Menu (or vice versa). This would be the same action as your proposed "user-initiated reload of the configuration file" using a known key combination.

[ExtremeFiretop]

@ExtremeFiretop,

I just submitted some simple changes to adjust the width to account for the possible long string of "ProductID / ModelID" in the rare cases where they happen to be different.

Here is a "fake example" just to illustrate the case.

Fantastic!

Thank you Martinski! I have the latest version and can see the adjusted widths now :)

[ExtremeFiretop]

@ExtremeFiretop,

I just submitted a new commit with improvements to the script-locking mechanism. Please use this latest code for testing & validation.

Got it! :)

[ExtremeFiretop]

Heere are significant changes to the way we used to do some things:

1. The "Lock" file now has a "type" parameter so that we can differentiate between "CLI Menu calls" vs "CLI option" calls.
2. There are 2 new CLI parameters:

Does this address the situation when someone has the shell script loaded and is playing with settings in the WebUI at the same time? That was the last issue I still had to address that was on my to-do list hahaha

Yes, that was the intended goal. One can have the SSH CLI menu open, while the WebGUI page is also running, and then select actions to perform. But, of course, they do not actively keep polling the configuration file so any changes made from one UI will not be reflected on the other immediately; you'll have to "refresh" the UI in order to re-read the modified configuration file. But this is the case for every add-on that is available out there; it would not be a unique limitation.

Might you consider adding additional menu options in shell script for both the main menu and the Advanced Options Menu to perform a user initiated menu refresh (i.e., reload configuration file on demand)? Skynet currently does this as "[r] --> Reload Menu".

I like the general idea but not as an explicit menu option duplicated in multiple places. What about some key combination that would trigger the "user-initiated reload of the configuration file" whether from the Main Menu or the Advanced Options menu? This way there are no duplicate options in different menus.

Yes, that would be a great way to implement it! I didn't like the duplicated menu options either, but without a way to initiate a reload from either menu, one would need to exit completely out of the script — your solution avoids that.

OK, it's on my to-do list :>).

Wow guys! I take time off and show up to work being done, I love this community sometimes!
You guys are great, love the imitative to push this project forwards!

@ExtremeFiretop,
I just submitted a new commit with improvements to the script-locking mechanism. Please use this latest code for testing & validation.

Testing with this latest commit (most likely not caused by commit), I discovered an inconsistency between how reloading settings do or do not happen when switching between main menu and Advanced Options Menu (or reverse) in shell script — toggling a checkbox is handled differently than chnaging value in text box.

Scenario:

1. Launch shell script. Note state of menu item 3 (F/W Update Check) and value of menu item 4 (F/W Update Postponement Days).
2. Launch web UI.
3. Toggle Enable F/W Check in web UI.
4. Change value of F/W Update Postponement in web UI.
5. In shell script (still on main menu page), enter "ad" to go to Advanced Options Menu, followed by "e" to return to main menu — menu item 3 toggled, but value of 4 remains unchanged.
6. Enter "e" to exit script.
7. Relaunch script. Both menu options now match web UI changes.

This scenario appears to be consistent when toggling checkboxes or changing values on both menus.

Suggested Solution: Force a reload of configuration file whenever switching from main menu to Advanced Options Menu (or vice versa). This would be the same action as your proposed "user-initiated reload of the configuration file" using a known key combination.

I can replicate this behavior as you describe it, will investigate a bit now.

[ExtremeFiretop]

@ExtremeFiretop,
I just submitted a new commit with improvements to the script-locking mechanism. Please use this latest code for testing & validation.

Testing with this latest commit (most likely not caused by commit), I discovered an inconsistency between how reloading settings do or do not happen when switching between main menu and Advanced Options Menu (or reverse) in shell script — toggling a checkbox is handled differently than chnaging value in text box.

Scenario:

1. Launch shell script. Note state of menu item 3 (F/W Update Check) and value of menu item 4 (F/W Update Postponement Days).
2. Launch web UI.
3. Toggle Enable F/W Check in web UI.
4. Change value of F/W Update Postponement in web UI.
5. In shell script (still on main menu page), enter "ad" to go to Advanced Options Menu, followed by "e" to return to main menu — menu item 3 toggled, but value of 4 remains unchanged.
6. Enter "e" to exit script.
7. Relaunch script. Both menu options now match web UI changes.

This scenario appears to be consistent when toggling checkboxes or changing values on both menus.

Suggested Solution: Force a reload of configuration file whenever switching from main menu to Advanced Options Menu (or vice versa). This would be the same action as your proposed "user-initiated reload of the configuration file" using a known key combination.

Seems to be the issue is that these values are only loaded once when the script is loaded currently and not when the menu is reloaded. (Such as the F/W Update Check setting)

The current lines at 1592 and 1593

FW_UpdatePostponementDays="$(Get_Custom_Setting FW_New_Update_Postponement_Days)"
FW_UpdateExpectedRunDate="$(Get_Custom_Setting FW_New_Update_Expected_Run_Date)"

Might want to be moved or replicated within the menu loop I'm assuming

[Martinski4GitHub]

@ExtremeFiretop & @TheS1R,

I just made a commit that addresses the issue reported by @TheS1R and also handles the "user-initiated reload of the configuration file" by typing the following key combination:

<Ctrl-R> + <Ctrl-L> (for reload) followed by the <Enter> key.
This key sequence works only while in the "Main Menu" and the "Advanced Options" menu.
Let me know if this works well during your testing & validation.

[Martinski4GitHub]

@ExtremeFiretop,
I just submitted a new commit with improvements to the script-locking mechanism. Please use this latest code for testing & validation.

Testing with this latest commit (most likely not caused by commit), I discovered an inconsistency between how reloading settings do or do not happen when switching between main menu and Advanced Options Menu (or reverse) in shell script — toggling a checkbox is handled differently than chnaging value in text box.

Scenario:

1. Launch shell script. Note state of menu item 3 (**F/W Update Check**) and value of menu item 4 (**F/W Update Postponement Day**s).

2. Launch web UI.

3. Toggle **Enable F/W Check** in web UI.

4. Change value of **F/W Update Postponement** in web UI.

5. In shell script (still on main menu page), enter "**ad**" to go to **Advanced Options Menu**, followed by "**e**" to return to main menu — menu item 3 toggled, but value of 4 remains unchanged.

Very good catch!! Please retest using the very latest script changes.

[ExtremeFiretop]

@ExtremeFiretop & @TheS1R,

I just made a commit that addresses the issue reported by @TheS1R and also handles the "user-initiated reload of the configuration file" by typing the following key combination:

<Ctrl-R> + <Ctrl-L> (for reload) followed by the <Enter> key. This key sequence works only while in the "Main Menu" and the "Advanced Options" menu. Let me know if this works well during your testing & validation.

Your quick and on the ball this morning @Martinski4GitHub !

Will test again shortly! Thanks for fixing the report!

[Martinski4GitHub]

@ExtremeFiretop & @TheS1R,
I just made a commit that addresses the issue reported by @TheS1R and also handles the "user-initiated reload of the configuration file" by typing the following key combination:
<Ctrl-R> + <Ctrl-L> (for reload) followed by the <Enter> key. This key sequence works only while in the "Main Menu" and the "Advanced Options" menu. Let me know if this works well during your testing & validation.

Your quick and on the ball this morning @Martinski4GitHub !

Will test again shortly! Thanks for fixing the report!

For the new "reload" key combination, I refactored & reused a lot of the code already written for the "offline" key sequence, so I decided to implement it while I had the solution "fresh" in mind this morning. It didn't take too long once I got rolling :>).

[TheS1R]

@ExtremeFiretop & @TheS1R,
I just made a commit that addresses the issue reported by @TheS1R and also handles the "user-initiated reload of the configuration file" by typing the following key combination:
<Ctrl-R> + <Ctrl-L> (for reload) followed by the <Enter> key. This key sequence works only while in the "Main Menu" and the "Advanced Options" menu. Let me know if this works well during your testing & validation.

Your quick and on the ball this morning @Martinski4GitHub !

Will test again shortly! Thanks for fixing the report!

Reload works perfectly for me!

I did encounter some anomalies when installing this latest script. FYI, to install, I have been executing the following script (I have a similar one for @ExtremeFiretop_'s repository_):

#!/bin/sh

curl --retry 3 "https://raw.githubusercontent.com/Martinski4GitHub/MerlinAutoUpdate-Router/WebFun/MerlinAU.sh"  \
     -o /jffs/scripts/MerlinAU.sh            && chmod 755 /jffs/scripts/MerlinAU.sh
curl --retry 3 "https://raw.githubusercontent.com/Martinski4GitHub/MerlinAutoUpdate-Router/WebFun/MerlinAU.asp" \
     -o /jffs/addons/MerlinAU.d/MerlinAU.asp && chmod 666 /jffs/addons/MerlinAU.d/MerlinAU.asp

sh /jffs/scripts/MerlinAU.sh startup

First, the script falsely detected a firmware update — I believe that I saw an error flash by about being unable to read the changelog. The email contents follows:

New Firmware Update for ASUS Router

A new F/W Update version 3006.102.2.2 is available for the GT-BE98_Pro router.

The F/W version that is currently installed:
3006.102.3.0_beta1

Number of days to postpone flashing the new F/W Update version: 5

Please click here to review the changelog:
https://sourceforge.net/projects/asuswrt-merlin/files/Documentation/Changelog-3006.txt/download

The firmware update is expected to occur on: 2025-01-16 00:00:00

Sent by the "MerlinAU" utility.
From the "TheRoutS1R" router.

2025-Jan-10 Fri 11:39:00 AM EST

Rerunning check for updates found none.

Second, I wound up with multiple instances of the MerlinAU web UI tab, namely user2.asp and user7.asp. To resolve, I removed two MerlinAU entries from menuTree.js, removed both .asp/.title pairs from /www/user, and I reran sh /jffs/scripts/MerlinAU startup.

[ExtremeFiretop]

Second, I wound up with multiple instances of the MerlinAU web UI tab, namely user2.asp and user7.asp. To resolve, I removed two MerlinAU entries from menuTree.js, removed both .asp/.title pairs from /www/user, and I reran sh /jffs/scripts/MerlinAU startup.

Huh... It shouldn't do that... I had scripted it to check the contents of MenuTree before attempting to append a new entry.

Will investigate momentarily

[TheS1R]

@ExtremeFiretop,
I just submitted a new commit with improvements to the script-locking mechanism. Please use this latest code for testing & validation.

Testing with this latest commit (most likely not caused by commit), I discovered an inconsistency between how reloading settings do or do not happen when switching between main menu and Advanced Options Menu (or reverse) in shell script — toggling a checkbox is handled differently than chnaging value in text box.
Scenario:

1. Launch shell script. Note state of menu item 3 (**F/W Update Check**) and value of menu item 4 (**F/W Update Postponement Day**s).

2. Launch web UI.

3. Toggle **Enable F/W Check** in web UI.

4. Change value of **F/W Update Postponement** in web UI.

5. In shell script (still on main menu page), enter "**ad**" to go to **Advanced Options Menu**, followed by "**e**" to return to main menu — menu item 3 toggled, but value of 4 remains unchanged.

Very good catch!! Please retest using the very latest script changes.

Thanks for addressing so quickly. Will test this afternoon. I have a meeting with financial advisor in 30 minutes (considering consolidating retirement accounts to one advisor going forward) so it will most likely be after that.

[TheS1R]

@ExtremeFiretop,
I just submitted a new commit with improvements to the script-locking mechanism. Please use this latest code for testing & validation.

Testing with this latest commit (most likely not caused by commit), I discovered an inconsistency between how reloading settings do or do not happen when switching between main menu and Advanced Options Menu (or reverse) in shell script — toggling a checkbox is handled differently than chnaging value in text box.
Scenario:

1. Launch shell script. Note state of menu item 3 (**F/W Update Check**) and value of menu item 4 (**F/W Update Postponement Day**s).

2. Launch web UI.

3. Toggle **Enable F/W Check** in web UI.

4. Change value of **F/W Update Postponement** in web UI.

5. In shell script (still on main menu page), enter "**ad**" to go to **Advanced Options Menu**, followed by "**e**" to return to main menu — menu item 3 toggled, but value of 4 remains unchanged.

Very good catch!! Please retest using the very latest script changes.

Thanks for addressing so quickly. Will test this afternoon. I have a meeting with financial advisor in 30 minutes (considering consolidating retirement accounts to one advisor going forward) so it will most likely be after that.

I had a few extra minutes to test this. Works perfectly now!

[Martinski4GitHub]

Another thing I've noticed: The scripts USB path does not update without closing the script completely and re-opened it completely.

Did you try the new key sequence <Ctrl-R> + <Ctrl-L> + <Enter> to reload & refresh?
That's the intended goal: to easily "refresh" the CLI menu whenever you have both the WebGUI page and CLI menu open?
Or, are you saying that the key sequence is not working for your case?

[ExtremeFiretop]

Another thing I've noticed: The scripts USB path does not update without closing the script completely and re-opened it completely.

Did you try the new key sequence <Ctrl-R> + <Ctrl-L> + <Enter> to reload & refresh? That's the intended goal: to easily "refresh" the CLI menu whenever you have both the WebGUI page and CLI menu open? Or, are you saying that the key sequence is not working for your case?

I'm unable to update the value at all from the WebUI if the script is running currently. But when I made the report; it was actually between switching from the main menu to the advance menu, without using the key sequence (which to my understanding is refreshing it similarly)

[ExtremeFiretop]

Another thing I've noticed: The scripts USB path does not update without closing the script completely and re-opened it completely.

Did you try the new key sequence <Ctrl-R> + <Ctrl-L> + <Enter> to reload & refresh? That's the intended goal: to easily "refresh" the CLI menu whenever you have both the WebGUI page and CLI menu open? Or, are you saying that the key sequence is not working for your case?

I'm unable to update the value at all from the WebUI if the script is running currently. But when I made the report; it was actually between switching from the main menu to the advance menu, without using the key sequence (which to my understanding is refreshing it similarly)

Okay; I found the problem why I was unable to update the value at all. That was still my bad.
And I can confirm that the key sequence works, but the updates to the path between menus does still does not update like the other values.

[Martinski4GitHub]

@Martinski4GitHub
Was this intended when disabling the Changelog check?

I think it may have been a little bug with the new visuals when it defaults to Disabled at line 382:
var approvalStatus = custom_settings.hasOwnProperty('FW_New_Update_Changelog_Approval') ? custom_settings.FW_New_Update_Changelog_Approval : "Disabled";

Ah, you're not using the very latest ASP file. Make sure you always load and install the very latest versions of the shell script & ASP files; otherwise, the test results & error reports are no longer meaningful.

Ah Yes; I see the version in my MerlinAU.d addons directory is outdated.

I had definitely updated the user1.asp from my /www/ directory before starting to test, but I guess I forgot to update the addons directory LOL

So when I reloaded the WebUI using the startup parameter to test @TheS1R report's; it created a second entry as he reported, and I obviously removed the good one and kept the the "old" version of my addons directory it reloaded which I forgot to update lol.

Ah, OK, understood. That's part of the "growing pains" when the code is still in flux & changing fast during the initial development where things are not yet "stable."

[Martinski4GitHub]

Another thing I've noticed: The scripts USB path does not update without closing the script completely and re-opened it completely.

Did you try the new key sequence <Ctrl-R> + <Ctrl-L> + <Enter> to reload & refresh? That's the intended goal: to easily "refresh" the CLI menu whenever you have both the WebGUI page and CLI menu open? Or, are you saying that the key sequence is not working for your case?

I'm unable to update the value at all from the WebUI if the script is running currently. But when I made the report; it was actually between switching from the main menu to the advance menu, without using the key sequence (which to my understanding is refreshing it similarly)

Okay; I found the problem why I was unable to update the value at all. That was still my bad. And I can confirm that the key sequence works, but the updates to the path between menus does still does not update like the other values.

Using the new key sequence to "reload & refresh" is currently the best way to make sure the CLI menus are accurately updated - short of exiting & relaunching the script.

Technically, users are not supposed to run & open both UIs at the same time, make configuration changes, and expect both UIs to automatically reflect those changes (even by switching menus). We're not dealing with that kind of real-time OS performing dynamic polling & refresh cycles. IMO, given the current "WebGUI + CLI menu" framework, the best we can do is provide an easy way for the user to initiate a "reload & refresh" of the CLI menus as needed. The new key sequence now provides that functionality. Anything else we do would be on a best-effort basis.

If and when the WebGUI page is released "to the wild" and comes online, my answer to users who complain about some CLI menu options not reflecting the values from the WebGUI while both are running at the same time will be: "Use the key combination to reload & refresh."

[ExtremeFiretop]

Another thing I've noticed: The scripts USB path does not update without closing the script completely and re-opened it completely.

Did you try the new key sequence <Ctrl-R> + <Ctrl-L> + <Enter> to reload & refresh? That's the intended goal: to easily "refresh" the CLI menu whenever you have both the WebGUI page and CLI menu open? Or, are you saying that the key sequence is not working for your case?

I'm unable to update the value at all from the WebUI if the script is running currently. But when I made the report; it was actually between switching from the main menu to the advance menu, without using the key sequence (which to my understanding is refreshing it similarly)

Okay; I found the problem why I was unable to update the value at all. That was still my bad. And I can confirm that the key sequence works, but the updates to the path between menus does still does not update like the other values.

Using the new key sequence to "reload & refresh" is currently the best way to make sure the CLI menus are accurately updated - short of exiting & relaunching the script.

Technically, users are not supposed to run & open both UIs at the same time, make configuration changes, and expect both UIs to automatically reflect those changes (even by switching menus). We're not dealing with that kind of real-time OS performing dynamic polling & refresh cycles. IMO, given the current "WebGUI + CLI menu" framework, the best we can do is provide an easy way for the user to initiate a "reload & refresh" of the CLI menus as needed. The new key sequence now provides that functionality. Anything else we do would be on a best-effort basis.

If and when the WebGUI page is released "to the wild" and comes online, my answer to users who complain about some CLI menu options not reflecting the values from the WebGUI while both are running at the same time will be: "Use the key combination to reload & refresh."

Okay perfect, that's enough of an explanation for me to note the key sequence as something we should add to the Wiki when we move to 1.4.0 with the WebUI!

Basically I can already see the potential of users going "it doesn't work like the other options!"

But at that point we will just forward them to the Wiki with this new entry to use the key sequence or close the script completely.

[Martinski4GitHub]

Another thing I've noticed: The scripts USB path does not update without closing the script completely and re-opened it completely.

Did you try the new key sequence <Ctrl-R> + <Ctrl-L> + <Enter> to reload & refresh? That's the intended goal: to easily "refresh" the CLI menu whenever you have both the WebGUI page and CLI menu open? Or, are you saying that the key sequence is not working for your case?

I'm unable to update the value at all from the WebUI if the script is running currently. But when I made the report; it was actually between switching from the main menu to the advance menu, without using the key sequence (which to my understanding is refreshing it similarly)

Okay; I found the problem why I was unable to update the value at all. That was still my bad. And I can confirm that the key sequence works, but the updates to the path between menus does still does not update like the other values.

Using the new key sequence to "reload & refresh" is currently the best way to make sure the CLI menus are accurately updated - short of exiting & relaunching the script.
Technically, users are not supposed to run & open both UIs at the same time, make configuration changes, and expect both UIs to automatically reflect those changes (even by switching menus). We're not dealing with that kind of real-time OS performing dynamic polling & refresh cycles. IMO, given the current "WebGUI + CLI menu" framework, the best we can do is provide an easy way for the user to initiate a "reload & refresh" of the CLI menus as needed. The new key sequence now provides that functionality. Anything else we do would be on a best-effort basis.
If and when the WebGUI page is released "to the wild" and comes online, my answer to users who complain about some CLI menu options not reflecting the values from the WebGUI while both are running at the same time will be: "Use the key combination to reload & refresh."

Okay perfect, that's enough of an explanation for me to note the key sequence as something we should add to the Wiki when we move to 1.4.0 with the WebUI!

Basically I can already see the potential of users going "it doesn't work like the other options!"

But at that point we will just forward them to the Wiki with this new entry to use the key sequence or close the script completely.

I can also see at least one user complaining about the WebGUI page not "refreshing" automatically after some configuration change is made via the CLI menu while both are running at the same time. The possible scenarios can start to get silly if users expect that both UIs are supposed to refresh automatically with changes made by any one of the UIs.

Honestly, my short answer in all cases will be:
"Do not run both UIs at the same time, make changes & expect both to be refreshed automatically."

[TheS1R]

Another thing I've noticed: The scripts USB path does not update without closing the script completely and re-opened it completely.

Did you try the new key sequence <Ctrl-R> + <Ctrl-L> + <Enter> to reload & refresh? That's the intended goal: to easily "refresh" the CLI menu whenever you have both the WebGUI page and CLI menu open? Or, are you saying that the key sequence is not working for your case?

I'm unable to update the value at all from the WebUI if the script is running currently. But when I made the report; it was actually between switching from the main menu to the advance menu, without using the key sequence (which to my understanding is refreshing it similarly)

Okay; I found the problem why I was unable to update the value at all. That was still my bad. And I can confirm that the key sequence works, but the updates to the path between menus does still does not update like the other values.

Using the new key sequence to "reload & refresh" is currently the best way to make sure the CLI menus are accurately updated - short of exiting & relaunching the script.
Technically, users are not supposed to run & open both UIs at the same time, make configuration changes, and expect both UIs to automatically reflect those changes (even by switching menus). We're not dealing with that kind of real-time OS performing dynamic polling & refresh cycles. IMO, given the current "WebGUI + CLI menu" framework, the best we can do is provide an easy way for the user to initiate a "reload & refresh" of the CLI menus as needed. The new key sequence now provides that functionality. Anything else we do would be on a best-effort basis.
If and when the WebGUI page is released "to the wild" and comes online, my answer to users who complain about some CLI menu options not reflecting the values from the WebGUI while both are running at the same time will be: "Use the key combination to reload & refresh."

Okay perfect, that's enough of an explanation for me to note the key sequence as something we should add to the Wiki when we move to 1.4.0 with the WebUI!
Basically I can already see the potential of users going "it doesn't work like the other options!"
But at that point we will just forward them to the Wiki with this new entry to use the key sequence or close the script completely.

I can also see at least one user complaining about the WebGUI page not "refreshing" automatically after some configuration change is made via the CLI menu while both are running at the same time. The possible scenarios can start to get silly if users expect that both UIs are supposed to refresh automatically with changes made by any one of the UIs.

Honestly, my short answer in all cases will be: "Do not run both UIs at the same time, make changes & expect both to be refreshed automatically."

Or, "Use the browser's equivalent of the script's key sequence to reload and refresh!" (aka refresh browser window)

[ExtremeFiretop]

This can be removed when going to production

[Martinski4GitHub]

@ExtremeFiretop,

I just committed new changes to make mounting the WebGUI page more robust.
Also, I added a fix for the problem you found when calling the script with the "run_now" parameter.

[ExtremeFiretop]

Some outstanding things I'll check into tomorrow:

1. Uninstalling MerlinAU did not remove this line: if echo "$2" | /bin/grep -q "MerlinAU"; then { /jffs/scripts/MerlinAU.sh service_event "$@" & }; fi # MerlinAU

2. from the service-event script file.

3. Upgrading from 1.3.9 to 1.4.0 did not automatically load the WebUI; I still have to manually run startup parameter

Off to bed for now, goodnight buddy! I'll be up bright and early tomorrow to poke at this more with you ;)

[Martinski4GitHub]

Some outstanding things I'll check into tomorrow:

1. Uninstalling MerlinAU did not remove this line: if echo "$2" | /bin/grep -q "MerlinAU"; then { /jffs/scripts/MerlinAU.sh service_event "$@" & }; fi # MerlinAU from the service-event script file.

2. Upgrading from 1.3.9 to 1.4.0 did not automatically load the WebUI; I still have to manually run startup parameter

Off to bed for now, goodnight buddy! I'll be up bright and early tomorrow to poke at this more with you ;)

Yeah, I noticed the 1st issue today when I was testing, so it was on my to-do list.
The 2nd one I have not been able to fully test & validate. Good catch!!
Have a good night, bud!!

[ExtremeFiretop]

Some outstanding things I'll check into tomorrow:

1. Uninstalling MerlinAU did not remove this line: if echo "$2" | /bin/grep -q "MerlinAU"; then { /jffs/scripts/MerlinAU.sh service_event "$@" & }; fi # MerlinAU from the service-event script file.

2. Upgrading from 1.3.9 to 1.4.0 did not automatically load the WebUI; I still have to manually run startup parameter

Off to bed for now, goodnight buddy! I'll be up bright and early tomorrow to poke at this more with you ;)

Yeah, I noticed the 1st issue today when I was testing, so it was on my to-do list. The 2nd one I have not been able to fully test & validate. Good catch!! Have a good night, bud!!

Like you said in the forums, slowly but surely we will get there!

It's not a small over-hall. I mean, it started fairly large with my PR and now looking at it with yours merged it, it's just very apparent how much of an over-hall it is.

I can tell while reviewing the PR that some of the shell script changes weren't strictly required, things like renaming or moving some functions may have not been required but it does look much cleaner so in the end it's an improvement all the same.

Half of the reported stuff in this PR I could of addressed in mine, but I didn't want to cause too much of a merge conflict so I figured we would work one PR at a time.

Tomorrow, back to mine (unless you come up with fixes first)

[ExtremeFiretop]

@Martinski4GitHub

Also worth mentioning; I just completed my first ever update, triggered by the WebUI. No CLI at all.
We are so close!

[Martinski4GitHub]

Some outstanding things I'll check into tomorrow:

1. Uninstalling MerlinAU did not remove this line: if echo "$2" | /bin/grep -q "MerlinAU"; then { /jffs/scripts/MerlinAU.sh service_event "$@" & }; fi # MerlinAU from the service-event script file.

2. Upgrading from 1.3.9 to 1.4.0 did not automatically load the WebUI; I still have to manually run startup parameter

Off to bed for now, goodnight buddy! I'll be up bright and early tomorrow to poke at this more with you ;)

Yeah, I noticed the 1st issue today when I was testing, so it was on my to-do list. The 2nd one I have not been able to fully test & validate. Good catch!! Have a good night, bud!!

Like you said in the forums, slowly but surely we will get there!

It's not a small over-hall. I mean, it started fairly large with my PR and now looking at it with yours merged it, it's just very apparent how much of an over-hall it is.

Oh yeah, adding a WebGUI is not a slam dunk!! There's a lot of new functionality that needs to be created just in the shell script alone (in addition to all the new code in the ASP file), and "old code" needs to be modified to account for the new interactions between the WebGUI and the shell script (e.g. lock mechanism). So yeah, it's going to take some time.

I can tell while reviewing the PR that some of the shell script changes weren't strictly required, things like renaming or moving some functions may have not been required but it does look much cleaner so in the end it's an improvement all the same.

Honestly, for a long time, I've been wanting to rename some variables because of the warnings I keep getting from the Linter tool. Variable names like "SETTINGSFILE" & "SCRIPTVERPATH" trigger a coding style warning (using all capital letters without any "spacing" (i.e. underscore) is considered a "bad" coding practice). Since adding the WebGUI requires a major overhaul of the code, I decided to do some renaming, especially after the 850+ warnings I got from running the Linter tool on your original PoC code. It's certainly much cleaner now, and it makes it easier to read & review.

Half of the reported stuff in this PR I could of addressed in mine, but I didn't want to cause too much of a merge conflict so I figured we would work one PR at a time.

Good call!!

[Martinski4GitHub]

@Martinski4GitHub

Also worth mentioning; I just completed my first ever update, triggered by the WebUI. No CLI at all. We are so close!

Yeah, we're getting there, inching closer, although, IMO, I think we're still at least a month away from a Beta test release.
There are some areas that I still need to review more closely, double-check, and test, both in the shell script and the ASP file. Nothing critical, but I still would like to review & validate them before calling them "ready."

[Martinski4GitHub]

Some outstanding things I'll check into tomorrow:

Uninstalling MerlinAU did not remove this line: if echo "$2" | /bin/grep -q "MerlinAU"; then { /jffs/scripts/MerlinAU.sh service_event "$@" & }; fi # MerlinAU from the service-event script file.

This is fixed with the latest PR #386
Please test & validate whenever you get a chance.

[TheS1R]

One other style issue that I noticed in the web UI, a nit but worth considering nonetheless... For Router Login Password field, the "eye" to show contents of a hidden text box is typically contained within the text box as opposed to outside the box and to the right.

Overall, this beast is coming together wonderfully!

[ExtremeFiretop]

One other style issue that I noticed in the web UI, a nit but worth considering nonetheless... For Router Login Password field, the "eye" to show contents of a hidden text box is typically contained within the text box as opposed to outside the box and to the right. Overall, this beast is coming together wonderfully!

Interesting nit-pick, because I didn't even consider it when I added the eye.

You are correct, lots of the time the eye is in the password text box, however to be completely honest, I'm pretty sure my method was just the easier one to implement lol.

I can try to change the method; but it took me longer than I want to admit how to even capture the eye from the WebUI in the first place so we could use it LOL.

[ExtremeFiretop]

One other style issue that I noticed in the web UI, a nit but worth considering nonetheless... For Router Login Password field, the "eye" to show contents of a hidden text box is typically contained within the text box as opposed to outside the box and to the right. Overall, this beast is coming together wonderfully!

So far this is the best i've got:

[ExtremeFiretop]

One other style issue that I noticed in the web UI, a nit but worth considering nonetheless... For Router Login Password field, the "eye" to show contents of a hidden text box is typically contained within the text box as opposed to outside the box and to the right. Overall, this beast is coming together wonderfully!

Submitted PR: #387
To address this suggestion. Example below: