Hi,

At some point between 7.x-2.x+dev-26 and 7.x-2.x+56, on line 19 of draggableviews.module, the condition changed from:

  if (isset($form['draggableviews']) && !empty($form['draggableviews'])) {

to...

  if (!isset($form['draggableviews']) || empty($form['draggableviews'])) {

I'm not sure of the reason for this change, but it's causing other forms that might appear on the View to lose their submit button. Specifically this is affecting a View that has both draggableviews and views_bulk_operations enabled. The VBO confirmation form does not have it's "Confirm" button because the condition above causes it's #access to be set to false.

I'm not submitting a patch because all I would do is revert the condition back to the way it was in 7.x-2.x+dev-26, but there might be a very good reason why it changed from && to ||.

Any thoughts?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

JonMcL’s picture

Actually, things get worse on further investigation :(

It seems that draggableviews_form_alter is also changing VBO's "Confirm" button to the draggableviews save_button_label option value. It's also overriding VBO's submit button function with it's own (draggableviews_views_submit). I'm fairly confident that wasn't happening with 7.x-2.x+dev-26.

Maybe just add:

  if (!isset($form['draggableviews'])) return;

as the first line of the draggableviews_form_alter function?

sinasalek’s picture

Status: Active » Needs review

Putting the line mentioned by @JonMcL fixed the problem for me, not side effects spotted

function draggableviews_form_alter(&$form, &$form_state, $form_id) {
  if (!isset($form['draggableviews'])) return;
SocialNicheGuru’s picture

i can't seem to get past this.

I have vbo and draggable enabled.
I can sort in one view
it says that it is saved
when I do a browser refresh the view returns to it's old order.

philipz’s picture

Is your view ordered by Field API or native handler? Is the field or native handler weight added to view's sorting as its first element?

SocialNicheGuru’s picture

native.
it is. I removed all other sort criteria.

while I can move the fields in the table and it says it is saved, a refresh undoes it all.

philipz’s picture

There is sometimes a problem with arguments if you have any exposed filters on the view. I've noticed on some of my views that I needed to set "Do not use any arguments" on the Draggableviews: Weight settings. Also I'm not sure but you might try removing exposed filters if you have any and then check if it works.

SocialNicheGuru’s picture

all of my fields have a field reference.
I defined a reference in my view
so the title is (field_reference)title

Do I need to do the same for the draggable sort and content fields in my control view so that:
(field_referenence)draggable_sort in the sort section
(field_reference)draggable_content in the fields section

philipz’s picture

Sounds like you have some advanced setup. You should open separate issue for it and describe your setup in detail.

iStryker’s picture

I think patch #2 of https://www.drupal.org/node/2314575#comment-9573367, might solve this

#2314575: Notice: Undefined offset: 0 in draggableviews_form_alter()

Patch changes

-  if (!isset($form['draggableviews']) || empty($form['draggableviews'])) {
+  if (!isset($form['draggableviews'][0]) || empty($form['draggableviews'])) {
iStryker’s picture

Title: draggableviews_form_alter disables Views Bulk Operations » Work with Views Bulk Operations
Category: Bug report » Feature request
Status: Needs review » Needs work

Nevermind #9 doesn't work. Draggableviews disables and hides its save button when the results are empty. It needs this. #2 only works because draggableviews_post_render hides the save button.

I'll work on a patch later today for this, I think I have an idea.

Changing title and marking as feature request. VBO use the same form as Draggableviews. Conflicts are bound to happen. I am surprise there is not more.

iStryker’s picture

Status: Needs work » Needs review
Related issues: -#2314575: Notice: Undefined offset: 0 in draggableviews_form_alter()
FileSize
4.46 KB

Alright I think I got it. Stole a lot of things VBO did in its hook_form_alter() and replace them in DV hook_form_alter().

Summary of Patch

  • Rewrote the ugly 'if form is draggable and is empty then remove submit button'.
  • Added exception for VBO, because we are both trying to leave the form action button alone if there is another handler present.
  • Instead of using view_form submit button, created a new button.
  • Used VBO methods to deterimine if this is a view_form

Patch is against the latest dev.

iStryker’s picture

New patch. Next button does not work #1914890: Next button missing in modify values action (VBO). Fixed in new patch.

iStryker’s picture

Want to get this into 7.x-2.2. Adding Parent

thomas.lobjoie’s picture

#12 works fine... thanks!

pfrilling’s picture

The patch in #12 is also working for me.

  • iStryker committed 75bed85 on 7.x-2.x
    Issue #2013839 by iStryker: Work with Views Bulk Operations
    
iStryker’s picture

Status: Needs review » Fixed

Awesome, committed.

  • iStryker committed 75bed85 on 8.x-1.x
    Issue #2013839 by iStryker: Work with Views Bulk Operations
    

Status: Fixed » Closed (fixed)

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