I'm doing something potentially outside the scope of the module. I've setup a draggable view using the cck handler. I've also setup link fields for my nodes that allow child nodes to be added, via a popup, dynamically from within the view and automatically prepopulated with the parent NID in the nodereference field of the child. It all works well from the nodereference side of creating the hiearchy, but something is wrond with the draggable views integration. The error I'm receiving on adding new children (in addition to the standard broken structure errors) is:
Something wrong in _draggableviews_ascending_numbers (WRITE).
Subsequently, I have to then refresh the draggable view a number of times. Sometimes this fixes the errors and the hierarchy is saved as expected, and sometimes no amount of refreshing or clicking of save will make the errors go away. Any idea what is causing this problem?

Comments

sevi’s picture

sevi commented

I also experienced the same error in a similar context. I think I already know the problem but I couldn't fix it so far.

NID    Title         weight    parent
1     Node1            0          0
2     Node2            1          1
3     Node3            2          2

When now Node4 is placed between 1 and 2 the view will not be repaired reliably (sometimes yes, sometimes no; depending on luck, because they have the same weights).

NID    Title         weight    parent
1     Node1            0          0
4     Node4            0          0
2     Node2            1          1
3     Node3            2          2

I'll try to fix this in the next days.

sevi’s picture

sevi commented
Status: Active » Fixed

I introduced a new variable $safe_offset (always < 1, in +0.0001 steps) that is added to all order values before the structure is going to be repaired.
In other words: All order values are now unique.
This will assure that child nodes always appear right after their parents even if there are other nodes with same order values.

http://drupal.org/cvs?commit=238438

The issue should be fixed now.
Please try and report.
Greetings,
sevi

looplog’s picture

looplog commented

Thanks for the quick turnaround. I'm still receiving the error message, and child nodes are still initially added out of place in the tree, but I suspect this may be something to do with my using popup_api to represent the node add page in a modal window. The repairing of the structure seems to be consistent, requiring only a single refresh. A definite improvement.

sevi’s picture

sevi commented

After the result of the view has changed - however you accomplish this - there should only appear the standard broken message once at all. Also the view should be re-executed after it has been repaired automatically and thus your child nodes should never appear out of place. But due to the way you add nodes this might be different.
The error message Something wrong in _draggableviews_ascending_numbers (WRITE). should not appear any more.

looplog’s picture

looplog commented

I think my issues are most definitely related to my use of popups to add new nodes. I've tested extensively, and a single manual refresh will fix the structure every time. My guess is that eliminating this step would require popups to send a callback on node submit and for the view to refresh as a response. At least as far as my poor knowledge of what is going on can figure out. There are the Ajax and Ajax_views_refresh modules that promise to be able to fix this, but they are not compatible with popups so for now I'll just have to learn to love the refresh button! Regardless, these issues seem to be outside of the scope of draggable_views.

FYI, the errors remain, but as I said, a manual refresh is enough to fix. These are the exact errors:


    * popup_edit_test node_title has been created.
    * The structure was broken. It has been repaired.

    * Something wrong in _draggableviews_ascending_numbers (WRITE).
    * Draggableviews: Rebuilding structure didn't work. The structure is broken.

Again, thanks for fixing.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.