Up and down arrows just destroy an unsaved slot

[boutell]

If you click the up or down arrows on a slot that's never been saved it is lost entirely. This is lousy if you're trying to add a slot at the bottom so you start by trying to move it there. Making this actually work is quite a problem, so please hide or gray out the up and down arrows for slots that are new ($slot->isNew()).

[johnnybenson]

I checked this out, added an if statement around the move arrows for the new slot,
but it doesn't really solve the problem.

The problem persists because there are still move arrows on the other slots. Moving any slot in an area with an opened editable slot will cause it to disappear.

It doesn't matter if it's new or old. If you're in an editing state with unsaved information and you move any slot at all, it will re-load that area via ajax and you will lose your changes.

Screenshot with arrows removed from new slot

I don't think this solves anything and I am going to revert this change.

Option A
Either there needs to be a Save action called on every open slot before a move occurs. This is the "behind the scenes don't have to think about it" solution in my opinion.

Option B
Or there needs to be some kind of editing state, where the page can be aware that editing is taking place and the arrows can dim or disappear. This could be accomplished with a body class potentially and some clever CSS.

But I'd rather have drag and drop than solve this issue with the arrows - I think Option A lends itself to moving in that direction anyway.

[tboutell]

How about for now we just disable the relevant controls while editing is in progress on any slot? Do you need help from me on that?

Buttons to add slots at both top and bottom of the area would do more in the near term to solve the related problem of users not actually being able to conveniently start slots where they want them.

The slot forms might not validate in your "emergency save, you're being moved" scenario, that sounds very complex to implement at least in 1.x.

[tboutell]

This is fixed in [2144]. It's satisfactory but two things would make it better:

TODO: strip down the response from the server to a yea or a nay.
TODO: actually do something about a nay (like refreshing the area).

I also fixed the fact that a-new-slot was not being cleared on the first save of a slot.

[tboutell]

This is fixed in the trunk, not 1.4.x. It will be in 1.5.