Reordering fails with high volume of posts and WPML

[rmpel]

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.

[helen]

Thanks for opening an issue for discussion @rmpel, and apologies for not getting back around to it sooner. @jakemgold and I have definitely talked a few times about moving to direct/batch queries - including shortly before you opened your PR, actually. The part we always seem to get stuck at is what hooks to trigger that would normally be called with wp_update_post(), if any. It's entirely possible we decide to just leave it as only calling the hooks for the post that was moved or even none at all, we just need to make sure it's been thoroughly considered especially for common use cases/plugins.

Do you have any sense of what exactly is going so slowly and what WPML is doing that causes it? It sounds rather like something is looping back and re-applying the ordering based on your description, since the plugin only triggers the reordering when using drag and drop. I've tested with a couple thousand pages and it's been a little slow on first reorder but not to the extent you're describing.

As for the approach itself, it may be good for us to figure out some controlled tests (automated or not) to compare speeds so we know for sure we are moving in the right direction. So for instance, a fresh ordering where none of the pages have a menu order assigned yet, moving 5 spots, moving 20 spots, moving a child page, and so forth.

[rmpel]

No Problem, better to have a late, thought through answer than a fast off-the-shelf response. I must admit, the query I wrote will probably mess up the order when all (or most) orders are identical; this is easily solved by adding a “, post_title ASC” in the initial order clause, so the posts are sorted by title if same menu_order. I am confident any issue can be resolved, with a little patience :) As to what might cause the problem, I really have no clue. We have been testing with a duplicate of the website with the original plugin and found that there might be a third factor involved; server response time. Somehow when the server is busy, the problem gets worse. Easy solution is to be patient, but users… well… they don’t really know what the word means ;) I’m sorry I don’t have any more insight in the problem, if you need me to run some tests, let me know, I can arrange the time to get that done :) With kind regards, Remon Pel www.clearsite.nl <https://www.clearsite.nl/?utm_source=email> | 030 264 06 05 <tel:+31302640605> | view portfolio <https://www.clearsite.nl/werk/?utm_source=email&utm_campaign=portfolio> <https://www.clearsite.nl/werk/?utm_source=email&utm_campaign=portfolio&utm_medium=icon>

…

On 2 May 2018, at 04:12, Helen Hou-Sandi ***@***.***> wrote: Thanks for opening an issue for discussion @rmpel <https://github.com/rmpel>, and apologies for not getting back around to it sooner. @jakemgold <https://github.com/jakemgold> and I have definitely talked a few times about moving to direct/batch queries - including shortly before you opened your PR, actually. The part we always seem to get stuck at is what hooks to trigger that would normally be called with wp_update_post(), if any. It's entirely possible we decide to just leave it as only calling the hooks for the post that was moved or even none at all, we just need to make sure it's been thoroughly considered especially for common use cases/plugins. Do you have any sense of what exactly is going so slowly and what WPML is doing that causes it? It sounds rather like something is looping back and re-applying the ordering based on your description, since the plugin only triggers the reordering when using drag and drop. I've tested with a couple thousand pages and it's been a little slow on first reorder but not to the extent you're describing. As for the approach itself, it may be good for us to figure out some controlled tests (automated or not) to compare speeds so we know for sure we are moving in the right direction. So for instance, a fresh ordering where none of the pages have a menu order assigned yet, moving 5 spots, moving 20 spots, moving a child page, and so forth. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABCVOLYIkEGAUL-JiEC9JkEcU2OP0QMTks5tuRYqgaJpZM4TTrDA>.