Update info on Emoncms input process list page

Looking at my post

I have looked at process_processlist.php and would like to add commentary to each process that makes it clear if the output is modified or not (even for the glaringly obvious ones!).

I have started with changes like those attached at .txt, using consistent wording, replacing existing notes where they say the same; I also - unrelated - changed “Scales” to “Multiplies” to stay consistent with other descriptions further down.

If this makes sense I am happy to continue through the list, but if it goes against any other work or effort please let me know.

Making readable word diffs is hard, I have just attached my php file - the changes are up to $list[21] for now.

process_processlist.txt (47.2 KB)



Hi Peter,

Sounds like a good idea! Could you create a pull request (edit the file directly on github if that’s easiest).

If you are not familiar with github see:

Once a pull request is open we will be able to more easily review then merge your changes.

Done, Updates to process_processlist.php by pgalbavy · Pull Request #657 · emoncms/emoncms · GitHub

It’s a first step - I would like to do more.

One Q though - some of this could be automated when the list is used (e.g. “redisrequired”) and we can also maybe add a “constant” type tag - but I don’t know where the UI turns the list into the displayed page.


I eventually found

I notice that this is perhaps where standard structure could be added to the “desc” based on the other process settings. I’m not quite brave enough to do that, given I don’t know the other dependencies, but I would think it would be more consistent for future maintainers.


Great! Thanks a lot.

I have justed tested, and made a small change to the wording and merged. I hope you don’t mind the small tweak I did. At first glance it was not clear if the input process did or did not modify the output. I changed the wording to

Output: modified value passed onto next process step

Would you mind if I made this PM a public topic on the forum? That way we can more easily get input for other users?


Happy to make this public, I just wasn’t sure where to start.

1 Like

Would there be any objections then to adding a new key to the process list items, something like ‘constant’ or ‘nochange’, and then using that and ‘requireredis’ to simply append the same type of commentary to each process desc text?

There are similar lists elsewhere in the Modules too aren’t there?

Finally, I would also suggest abstracting out all the process functions on a single dynamic help page, a bit like the API help pages. Again, not sure where to start (code base wise) with this though.

I don’t see this being an issue.

No sure, I can’t think of anywhere…

I agree, sounds like a good idea. It would be good to abstract the strings away from the code (like Android apps), this will allow the strings to be more easily translated and maintained in the future. I’m not sure how best to do this. We would need to ask @TrystanLea

Maybe I’m being thick, but I’ve made changes to Modules/process/Views/process_ui.js and they are having no effect. I have not restarted anything, but I thought this was all dynamic? I will kick apache next.

UPDATE: Ignore, Chrome was being “helpful” and caching too much. CTRL-Shift-R works… or seems to.

1 Like

Found some in eventp and schedule, will also do those later.

Should that read:
value passed on to next process step
or perhaps,
value passed to next process step ?

My changes were meant to remove ambiguity - saying the value is passed on is unclear (to me). The intent is to be clear if the input value to that step is or is not changed. The “May change” is likely to go away with my next contribution.

The key word here is modified, as @peter mentions it’s important to state if the input process ‘modifies’ or ‘does NOT modify’ the input.

Try using Chrome ‘incognito’ mode when testing.

Git confuses me, but here is a new pull request with some more bits: Update processlist help text to use auto-append by pgalbavy · Pull Request #658 · emoncms/emoncms · GitHub

Thanks, merged.

Hi Glyn,

What I was asking about was the use of “onto” vice “on to.”

Going by: onto meaning “to a position on the surface of”

Ah! Well, the strings all in one place now, so change as you see fit.