Hi Jamie,
Good observation, and it’s fixed in 2.8.8.
One reassuring detail: what was being saved was always correct. WordPress re-nests children under their parent when the list is rebuilt, and the plugin never touches post_parent — so after a refresh the tree was exactly what you’d asked for. The problem was purely that the screen disagreed with the stored order until then, which understandably reads as a broken drag.
The cause is that WordPress renders a hierarchical list as one flat run of table rows, so the drag library moved only the row you grabbed. Every row carries a level-N class, so the plugin can now work out which rows are nested under the one being dragged and bring them along — for mouse dragging, and for the keyboard reordering too. Flat lists are unaffected.
To set expectations: this makes the display honest, but it isn’t full parent/child ordering yet. Dragging is still not constrained to an item’s own level, so you can drop a parent into the middle of another branch and it will take its children with it. Proper hierarchical ordering is tracked as issue #58 and is the main item for 2.9.0.
Thanks for the screencast — it made this quick to pin down.
Again, thank you so much for the prompt response and for fixing this. Tested and works. I’ll admit at first I didn’t think it was fixed because the children didn’t come along for the ride while dragging, but I soon realised this happens after dropping.
