Reordering doesn't work

it cant disable the reweighting and parent values as these are what save the table on update. patch to correct default core behavior is welcome but the default is always alphabetical in core. critical = doesnt work. we use this in production.

This bug affects reordering on every page it's available for example http://address/node/%nodeid/outline/children reordering is unreliable. Maybe not critical but definately annoying and gives buggy/unprofessional feeling.

thank you for your critique on my level of professionalness in development. Outline child pages is a bit of an oddity so please see if this is the case on the book admin form that outline designer was originally crafted to improve. I'll take a look at this issue when I get a chance, until then, everyone is welcome to dig in and work on patches to help along this project.

Sorry if I offended you, it wasn't my attent. Everybody who commits to community deserves nothing but respect. It's just how I thought it might look from customer point of view.

I tested this on book admin form and behaviour is the same.

ok, is this with a new outline or an existing one that you then apply outline designer to? Does it happen after you do a bunch of reordering or just on the first several tries? I've experienced this sporadically but is quickly resolved via a few drags.

I have only tried it with new outlines on clean install and it is the first few drags when it happens, then it usually is ok at least for a few drags.

I've replicated this. It resolves after a few times (not that thats acceptable I agree). It has to do with the item in question getting a new weighting but the items around it not being reweighed. This is a product of how the outline designer is now handling AJAX refreshes instead of the AHAH method in D6 (where the whole interface comes from). I'm in a crunch right now so this isn't high priority but will be something I look into soon.

This keeps me from using the module in my projects, although I love the rest of the features. Would it be possible to implement this as a draggable view instead? Or to take what draggable views does with core weights and apply it to outline designer?

hasn't stopped us yet; will always accept patches to add this critical functionality that has a current resolution of just dragging the items a few extra times.

I can't resolve it by dragging extra times, unless than number is greater than 3, at which point I stop trying. I saw your comments on Twitter, and I did not mean to indicate I'm sitting on the sidelines until you resolve it. We did discuss this in another issue a few months ago, and I haven't done anything to try to fix it yet - so you are right to have that impression. I'm not a developer and don't know where to start. Would you be willing to point me in the right direction? We have a couple of developers that I can probably enlist to work on a patch.

My best guess is in /modules/outline_designer_book/js/overrides.js or , modules/outline_designer_book/outline_designer_book.module.

From there, I'm not sure what path we should take. Any advice is greatly appreciated.

Yes the overrides file is most likely where this is happening because I believe it's an issue associated with not submitting the entire interface. 1.x branch originally was double-submitting the interface to correctly update the drag-drops and I thought I fixed it w/ a 1 call structure that updated the outline items. It appears to be setting them all the to same weight and then defaulting to alphabetical. I've started to experience this, particularly with content created prior to creation via the outline designer or added into books manually (both of which I do).

This is a known issue so we can bump this up to dev since it's still happening there unfortunately. As per my venting, don't take it personally. Open source, and especially this project, is a labor of love; one that i too often get emotionally invested in. I've built my 20s around contributing to drupal.org and trying to help reduce costs in education through investment now for lower costs long term. It's a silly, over ambitious goal that keeps me motivated and at times overly so. You happen to post a similar message to several others I received in other queues. You are very engaged and I appreciate that.

As for any developer cycles you may be able to spare I'd appreciate them as always. ALl contributions, even problem identification and isolation, are good ones.

Now; back to the issue at hand. For the time being I'm doing some crazier projects / integrations and fixing this is on the back-burner for a bit but not off the radar.

Here's a patch (I think, it's my first contribution to drupal) that's working for me to fix this issue. It updates the weights of all items if at least one item's weight changes.

Looks viable; Only question, why $weight += 2;. Brian MacKinney / anyone else can you test this as I have trouble finding sites this happens on vs ones it doesn't. I'll give it a shot tomorrow and thank you for the contribution!

Patch works.

Patch seems to work for me. Might have another issue. Adding new content adds a + in spaces. (Ch. 5:.. becomes Ch.+5:...)

this patch shouldn't influence that; I'll roll the patch today and see if I notice any issues cropping up.

Please open a new issue for the + sign thing as well as indicate there if ALL spaces get it or if it's just when you start things w/ the Ch.{space}5 style beginning to the items

Originally I incremented the weight by +1, but switched to +2 to have more spread in the weights in case you are manually re-ordering on the outline tab of a node or something. +1 gives you (-11, -10 ... -1), while +2 gives you (-11, -9 ... 0 ... 9 , 11). Either is fine though.

The title issue is a separate issue. I had issues with renaming titles as well, and have a patch for that too if I can track it down.

patch comitted to dev, will be adding to a new RC3 now as this has been a lingering issue for awhile. Thank you datvance!

I'm still getting this problem.

Reordering the pages seems to have no effect, and I can't find a way to trigger the saving function.

Currently the only way to reorder a page is to reorder them and then create or change the name of a page to trigger the save function.

However if this isn't done then any changes are lost.

check console log about jquery errors, permission issues or something cause this works

Just to confirm, I think I got to the bottom of this, and it was conflicting with the BooksMadeSimple module which has a couple of similar operations.

(In the end the BooksMadeSimple module seemed to be doing everything I wanted this one to do, so I'm using that one instead - but if there is a conflict there it may be something to be aware of in the future).

Thanks.