In a situation with more posts than the batch processing does in one go and the multilingual plugin WPML, reordering fails when the new position is more than a few posts away from the original position
In our situation, the post was at menu_order 64 and needed to go to 10. I dragged the post, the menu_order reverted to 64 (no change)
when editing the post en using the menu_order meta box in the right column, change the value 64 to 10, and hit "update post", the value reverted to 64.
when editing the value directly in the database, from 64 to 10, re-opening the edit pane of the post, the value stated 10 and the post was at the correct position. When just hitting "update post" without changing any data on the edit page, the value reverted to 64.
I then proceeded to debugging the plugin, using error_log lines at specific points in the page and noticed that the reordering kept on going even after closing the browser, which made me realise; the reordering is going on still and being very slow.
I have built re-order algorithms lots of times in my long career and applied a series of database queries I thought up years ago;
multiply all order values by 2, even numbers are "current" positions
change the position of the dragged item to an odd number between the two items the item needs to go
renumber all posts starting at 1.
done.
In a situation with more posts than the batch processing does in one go and the multilingual plugin WPML, reordering fails when the new position is more than a few posts away from the original position
In our situation, the post was at menu_order 64 and needed to go to 10. I dragged the post, the menu_order reverted to 64 (no change)
when editing the post en using the menu_order meta box in the right column, change the value 64 to 10, and hit "update post", the value reverted to 64.
when editing the value directly in the database, from 64 to 10, re-opening the edit pane of the post, the value stated 10 and the post was at the correct position. When just hitting "update post" without changing any data on the edit page, the value reverted to 64.
I then proceeded to debugging the plugin, using error_log lines at specific points in the page and noticed that the reordering kept on going even after closing the browser, which made me realise; the reordering is going on still and being very slow.
I have built re-order algorithms lots of times in my long career and applied a series of database queries I thought up years ago;
multiply all order values by 2, even numbers are "current" positions
change the position of the dragged item to an odd number between the two items the item needs to go
renumber all posts starting at 1.
done.