Dashboard layout goes insane, becomes unrecoverable/uneditable

On Windows 10, running locally. Node 16.12.0, npm 8.1.0.

I can't run node 17.x.x because I need node-red-contrib-modbus and it's not compatible with anything newer than 16.x.x yet. I will upgrade when I can.

In the meantime, my dashboard layout goes insane when I add a single button to a group, now. I add the button, things move around as expected, but I can't move them back. The various elements in that group become bizarrely wide, e.g. a button that is defined as 4x1 when you look at the node is shown on the dashboard layout as 2 or 3 times that wide. All the other elements do the same. Once that occurs all I can do is literally delete all flows and re-import from a backup JSON file.

Others must have seen this behavior, certainly. Is there a fix?


Just commenting to say, I have also experienced this issue. It is quite troublesome when I have a large amount of dashboard nodes to sort it all out again.

As for not being able to move/resize them, make sure they haven't locked themselves or set to auto for size.

None are locked. And I explicitly control the size of every element. I do not allow anything to be set to automatic.

Another couple of observations: it seems this problem gets worse with smaller widget sizes. When I try to set 1x1 widget size to less than 36x36 things go crazy in a hurry. And groups that have gauge displays are also more susceptible.

Harold--forgot to ask: how do you "sort it out again"? For me it's fatal. I have to delete the flows and recover from a backup json file.

I've always been able to move them back, But sometimes I need to deploy before I can adjust them and have it to take hold.

Don't do that, node-red only supports LTS versions of nodejs (the even numbers) The odd numbers are effectively development versions on the way to the next LTS release. See also Supported Node versions : Node-RED.

Have you tried pressing ctrl+Z a few times? It is often possible to undo over a deploy.

To recover, if that doesn't work, it is much easier to keep a copy of your flows file. Then if things go wrong you can just replace the file with the backup and restart node-red.

Thanks for that, Colin, I did not realize that was the case. I will say that the problem I speak of is MUCH worse in 14.x.x. I was developing under 14 while waiting for the modbus stuff to catch up to 16 and was despairing that my design would be unrealizable because of the dashboard formatting issues. 16 largely, but not entirely, fixed this.

I'm running nvm under windows and have already used it to migrate from 14 to 16. Is there really any danger in trying an odd-numbered release, assuming good backups, of course?

Again, Colin, thanks for that. I'm feeling a bit silly, now, having been spending time exporting all flows as a means of backup rather than merely backing up flows.json.

Is it sufficient to just back up flows.json, or should I backup the entire C:\Users\username.node-red folder?

OK, enough thread drift, back on point: who, if anyone, has any information or work-arounds for when a group dashboard layout goes insane/becomes corrupted and simply cannot be properly rearranged again without recovering from a backup?

After doing that did you go into your .node-red folder and run
npm install
It is necessary to do that so that any nodes that require it are rebuilt with the new nodejs version. If you don't do that then unpredictable things may happen.

If your system is not controlling safety critical systems then there is no danger. There is a significant possibility that some things will not work. There have been a couple of reports here of problems where people were using 17, and reverting to 16 fixed it. I cannot see any benefit to using a version of nodejs that node-red has not been tested against.

Backup everything except the node_modules folder, which contains all the non-core nodes installed, can be very large and can easily be recreated. If you ever have to do a full restore then the recreation is done by going into the .node-red directory (after restoring it obviously) and running
npm install
That will re-install all the non-core nodes that have previously been installed.

I don't think many have seen this problem, which is why there has not been much response. If you can create a repeatable example with a minimal flow then no doubt it would get looked at.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.