Problem/Motivation

Thanks for the wonderful module. I have an issue may be it works as expected but still i am finding it some thing unusual. (from #2658358: Nodequeue view get reflected before it is saved on adding new story)

I am removing a node from a nodequeue with 10 no of nodes.
Then I add a new node in the queue which becomes the first node of the queue by default
I have not saved the queue till now cause i don't want the new node added in the first position, I want to put the new node to the 5th position.
But before I save the nodequeue the new added node shows in the first position of the view that was created using that nodequeue.
But the view should not get reflected before I save the queue.

Proposed resolution

We'll likely need to do a bunch of things to make this easier on people, but let's start with these:

User interface changes

TBD.

API changes

none.

Data model changes

none.

===
Additional related comments from #2538126: Removing node from queue reverted by node add
===

The current UI allows for some non-intuitive behaviour: in a fully populated four node queue, clicking "remove" (on, say, node 3), triggers a warning message that nodequeue state is not persisted ("Changes made in this table will not be saved until the form is submitted.") but using the autocomplete and "Add content" button to add a fifth node causes the previously removed node to be reinstated (and likely) the node in position 1 to be popped off the queue.

IMO, it's reasonable for a user to expect that "remove" did immediately remove the node (e.g. via XHR), or that clicking the "Add content" button submits the form (fulfilling the action described in the warning message), or that clicking "Add content" is similarly provisional and final nodequeue state requires submission via Save button.

===
Original Issue:
===

On nodequeue admin view at website.com/admin/structure/nodequeue/1/view/1 interface allows to add and remove nodes from queue.
I've been looking in functionality of removing node from nodeque and found that it is a regular link to menu callback. As i understand this approach is very wrong.
Imagine situation when nodequeue is fixed size (for example 4 items) if i want to replace 3rd element i have to delete it and then add new and rearrange then hit Save.
But instead of this when i remove node, view on front page gets updated (contains only 3 elements)
When i add node view on front page also gets updated but order is wrong.
If page cache it turned on and has big lifetime this bug makes some troubles.

I'm thinking of re-building this page using FAPI and ajax buttons for remove. When any action is done form should make an AJAX call that should not perform any operations only store operations list that will be performed on submit handler.

Comments

dmitriy.pokhodenko’s picture

Issue summary: View changes
holypoly’s picture

I have the same issue on my site and this is a bad bug that the queue is modified before we hit "save" on the nodequeue. Does anyone have a solution or a patch for this so this does not save unless we hit the "save" button??

jenlampton’s picture

Title: When removing or adding node to nodeque it appears in all views that use this nodeque even before i save nodeque. » Unable to add/remove+rearrange nodes to queue without also saving before all desired changes are made
Category: Bug report » Support request

The nodequeue *is* saved as soon as you hit the "Add content" button. All the "Save" button saves is the order of the items in the queue. The buttons do not clearly indicate what happens when you click them, which can set the wrong expectations for people when adding items to the queue.

The first poster is correct that it would be better if nodequeues had some sort of temporary storage mechanism so that all three operations could be performed at once, requiring only one single save. Doing them separately does cause the problems mentioned in the first post.

I'm not sure if this qualifies as a bug report, but it certainly is confusing. I'm reclassifying as a support request for now, but if we can figure out a new feature to request from it, perhaps it can be reclassified again.

jenlampton’s picture

Issue summary: View changes
jenlampton’s picture

jenlampton’s picture

Issue summary: View changes