EmonCMS 9.8.2 | 2017.03.03

[chaveiro]

Bug fixes
Added check for infinite recursive loops on process lists.
Added expanded tables support.
Added loading spinner across ui modules.

[TrystanLea]

Thanks @chaveiro looks great from a quick read through, shall I merge? I havent tested here yet.

[Paul-Reed]

I didn't have much time this morning, but the git patch failed for me so couldn't test. I'll try again this evening when I've got more time...

…

On 3 Mar 2017 10:00, "Trystan Lea" ***@***.***> wrote: Thanks @chaveiro <https://github.com/chaveiro> looks great from a quick read through, shall I merge? I havent tested here yet. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#648 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA7bDGeXfNy2lKxMog1yl8B5C2vxE8V5ks5rh-SzgaJpZM4MR5X7> .

[TrystanLea]

A quick test, I cant see any problems, it does require a new instance of settings.php.

[Paul-Reed]

Works fine here, although;

Added expanded tables support.
Should we see a change? the tables appear and perform the same.

Added loading spinner across ui modules.
After throttling the network and loading the apps, I'm not seeing the spinner.
I can see via browser tools that ajax-loader.gif is loading - just can't see it.

[chaveiro]

Hi Paul, that is the app module, i did't touch it. Its on its own repo.

[Paul-Reed]

Nuno, please forgive my ignorance, but which ui modules does it apply to? I don't see the spinner at all despite throttling the bandwidth.
If it doesn't apply to the apps, why are the apps loading ajax-loader.gif?

Paul

[chaveiro]

Hi, on this commit, the ajax-loader.gif is used only in place of the loading text that the input, feed and schedule modules used to shown while loading the table data.

[Paul-Reed]

Aahh right. It's a very subtle change, as even on a weak 2G signal, I only glimpse the spinner for a fraction of a second. However, it may be more obvious under more hostile network circumstances.

Thanks Nuno, looks fine here, no problems.

Paul

[Paul-Reed]

Was just in the process of merging, but noticed that default.emonpi.settings.php has not been updated, and an emonpi update would therefore fail due to the config_file_version flag being incorrect. (also allow_config_env_vars missing).

EDIT - I'll add them after merging.

Paul

[glynhudson]

Thanks guys. Nice work 👍

After a testing period I will merge into stable and handle an emonPi update. I'm thinking to perform and md5sum on the emonpi users settings.php to determine if it's been edited by the user. If it's not been edited by the user (probably most emonPi's) then we can safely swap out settings.php for default.emonpi.settings.php.

If the user has edited settings (md5sum compare fail) then I guess it will be down to the user to perform a manual update.

[jeremypoulter]

Maybe you should start looking at using a packaging system? You get that type of thing for free then, eg apt/dpkg will prompt the user to see if they want to keep the modified one, install the new one, view a diff, etc.

…

On Mar 5, 2017 12:03 AM, "Glyn Hudson" ***@***.***> wrote: Thanks guys. Nice work 👍 After a testing period I will merge into stable and handle an emonPi update. I'm thinking to perform and md5sum on the emonpi users settings.php to determine if it's been edited by the user. If it's not been edited by the user (probably most emonPi's) then we can safely swap out settings.php for default.emonpi.settings.php. If the user has edited settings (md5sum compare fail) then I guess it will be down to the user to perform a manual update. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#648 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF1WgMO6dczZLQshM6eEiqJTnq1Nz_kfks5rifvKgaJpZM4MR5X7> .